[Tutor] Exception Handling and Stack traces

[Steven D'Aprano]

On Sat, 11 Sep 2010 04:47:13 am Michael Powe wrote:

> No problem, I am working on getting this sorted out.  The
> documentation seems to be written as reminder for people who already
> know how this stuff works, rather than as a clear explanation for
> anybody working with it.

That's because the job of documentation is to be documentation, not a 
tutorial.

Admittedly, sometimes it's hard to draw a line between the two, but you 
have to assume *some* knowledge of the reader -- imagine if every time 
you tried to document some piece of code, you had to start explaining 
what variables are.

In this case, the Fine Manual is plenty clear. The example in the 
tutorial shows:

try:
    ...
except ValueError:
    ...

http://docs.python.org/tutorial/errors.html#handling-exceptions


There's no need to add an error message to the ValueError:

# this does NOT work
except ValueError("I never know what message to expect"):

There's nothing in any of the documentation I've ever seen that suggests 
that catching an exception requires you to specify the exact error 
message. Since error messages are subject to change without warning, or 
translation into other languages, this wouldn't be practical even if it 
could work (which it doesn't).


It does require a bit more knowledge to decipher the main documentation:

http://docs.python.org/reference/compound_stmts.html#try
http://docs.python.org/reference/executionmodel.html#exceptions

but as I said, this is not a tutorial. They are written for 
non-beginners. If you need a tutorial, do the tutorial, and don't 
expect the documentation to be all things to all users.

Or read example code in the standard library. If you pick a random 
module and read it, you can expect to find exception handling. See what 
other coders do.


> Eventually, I arrived at a workable conclusion by wrapping only the
> call in main and using your suggested 'as' clause.

If you're focused on the 'as' clause part, you're still missing the 
point.


> This successfully 
> suppresses the traceback and gives a useable error message. 
> Although, in the case of URLError, 'getaddrinfo failed' may not
> actually mean much to the end user, it'll have to do.
>
> I don't like the fact that I cannot locate my thrown exception at the
> point of throwing

Of course you can.



> -- i.e., I don't necessarily mind catching the 
> exception in main but I would like to be able to print out exactly
> where the exception occurred.  This is more useful when
> troubleshooting. 

Err, that's exactly what the stacktrace is for -- it shows the execution 
chain that failed.

> However, an entire stacktrace is unacceptably verbose.

For who? You, the developer, or for an end user?

If you mean for an end user, I agree. Stack traces aren't written for 
them. 

If you mean for you, the developer, then I'm sorry, but I find that a 
bogus attitude. It's true that *most of the time* the only part of the 
stack trace that you (generic you) will look at is the final call, but 
there are many, many times when you need to see the entire call chain 
to determine what's going on.

Anyway, be glad this is Python. In a former life, I worked for a company 
that had just installed a SAP accounting application. One day the 
application crashed, and printed out a stack trace direct to the 
printer. It was over fifty pages of tightly-written 9pt font. 
Seriously.

We called the developers and asked what they wanted us to do with it, 
and they said to throw it out.


-- 
Steven D'Aprano