Simple way of handling errors

Stephen Hansen apt.shansen at gmail.com
Thu May 7 05:19:56 CEST 2009


> If it fails, you get both a straight-forward error message and a useful
> traceback:
>
> Traceback (most recent call last):
>  File "<stdin>", line 1, in <module>
> IOError: [Errno 2] No such file or directory: 'foomanchu'
>
>
> The only reason you would bother going to the time and effort of catching
> the error, printing your own error message, and then exiting, is if you
> explicitly want to hide the traceback from the user.
>

Unfortunately, I find that even halfway technically trained
(not necessarily naturally inclined or talented, but trained) users are
utterly unable to read tracebacks in real world situations. I had to put up
a rather big guide on how to read and interpret even the simplest ones
complete with color coding, "how to pick out a traceback visually", "what
line to focus your attention on (the last)", and "how trying to /read/ it
instead of immediately sending it to me as if it were an opaque symbol
containing secret knowledge only I can make sense of, generally saves you
time in debugging issues". I'm not talking about esoteric tracebacks either
resulting from real bugs and stuff. I'm talking about 'file not found'
'permission denied' IO/OS level ones that should give serious hints at
things people should check/diagnose themselves.

There's a serious, "oh my god, traceback, /eyes glazed over/" reaction all
around. Now these aren't unix people or command line people (except my
rote), but still.

I don't quite find printing out tracebacks to stdout or stderr ever
acceptable :( Especially if its an expected error condition (file not found
is a very good example of that).

I route all my tracebacks into log files for diagnosing later (people also
can not be relied upon to say anything but 'traceback' when they see one: so
storing it for later is vital. They read the first word and stop. The
thought of most-significant-information at the bottom is a difficult thing,
alas)

Anyways. ;-) That's just my experience.

As to the OP: try/except is how you do it in Python. There's no shorter or
easier way; exceptions are how Python handles failure-states (even
soft/expected errors quite often) and it does so pervasively (but not
universally).

--S
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20090506/01b24428/attachment.html>


More information about the Python-list mailing list