exception handling in complex Python programs

[Rafe]

On Aug 20, 12:19 am, eliben <eli... 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.
>
> 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 ?
>
> 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 ?
>
> 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-...
> Not really CL specific, and can apply to Python's exceptions.

Maybe I am oversimplifying (and I am here to learn), but I catch all
exceptions which otherwise would be hard to understand as a user. In
other words, when a better error message is useful.

Again, this is probably too simple to help, but the only way to ignore
certain types of exceptions, as far as I know, is to catch them and
pass.
e.g. this ignores type errors...

try:
    somethingBad()
except TypeError, err:
    pass
except Exception, err:
    raise TypeError(err)


I suppose you could write a decorator to do this if you want it at the
function level, but that seems a bit to broad. Shouldn't exceptions be
on a case-by-case basis to add protection and return information
exactly where it is needed?

- Rafe