exception handling in complex Python programs

[Chris Mellon]

On Tue, Aug 19, 2008 at 12:19 PM, eliben <eliben at gmail.com> wrote:
> Python provides a quite good and feature-complete exception handling
> mechanism for its programmers. This is good. But exceptions, like any
> complex construct, are difficult to use correctly, especially as
> programs get large.
>
> Most of the issues of exceptions are not specific to Python, but I
> sometimes feel that Python makes them more acute because of the free-n-
> easy manner in which it employs exceptions for its own uses and allows
> users to do the same.
>

Lots of people seem to have this fear. They treat exceptions like they
would treat error codes, trying to handle any possible case around any
particular call.

This is the wrong thing to do, and it only leads to more fragile code.
There are only 2 reasonable things to do with an exception:
1) handle it, by which I mean catch the exception knowing what error
condition it signifies, and take an appropriate action to correct the
error and
2) pass it up so something else has a chance at it.

Catching an exception when you don't know exactly what to do to fix it
is an error. At best, it will make debugging a program harder (because
you're losing context information about the error) and at worst it
adds bugs to your program. The way Javas checked exceptions encourage
empty or otherwise useless exception handlers is a major problem with
them.

There's some fear about presenting exceptions to the end user. That's
a user interface issues, not a software quality or engineering issue,
and it's resolvable with top-level handlers that log tracebacks
somewhere a user can't see them if desired.


> Now, what do I mean more specifically... When a program starts growing
> large, I find myself a bit scared of all the exceptions that might be
> thrown: Python's exceptions as a result of runtime-detection of errors
> (Python's dynamic typing also comes into play here), exceptions from
> libraries used by the code, and exceptions from my lower-level
> classes.
> Python doesn't allow to specify which exceptions are thrown (C++'s
> feature adding 'throw' after a function/method declaration specifying
> the exceptions that can be thrown), and this leaves me at loss - what
> should be caught and where ? Which errors should be left to
> propagate ?
>

You should catch anything that you can correct. If you don't have a
specific answer for a specific exception, don't catch it.

> I've tried looking around the Python blogosphere, but there doesn't
> seem to be much concern with this topic.
>
> Apologies for the not-too-coherent post, but I suspect you feel the
> pain too and can understand my meaning.
>
> Eli
>
> P.S. There's a common case where a method is passed a filename, to do
> something with a file (say, read data). Should the method catch the
> errors possibly thrown by open(), or leave it to the caller ?
>

Same rules apply. The only sort-of exception (no pun intended) is that
sometimes you want to re-raise as a different type of exception. Make
sure that you preserve all of the original information (including the
original traceback) if you do this.

> P.P.S. There's a great post on conditions (Common Lisp's exceptions)
> here:
> http://dlweinreb.wordpress.com/2008/03/24/what-conditions-exceptions-are-really-about/
> Not really CL specific, and can apply to Python's exceptions.
> --
> http://mail.python.org/mailman/listinfo/python-list
>