How to except the unexpected?

Peter Hansen peter at engcorp.com
Sat Mar 4 02:01:19 CET 2006


Rene Pijlman wrote:
> One of the things I dislike about Java is the need to declare exceptions
> as part of an interface or class definition. But perhaps Java got this
> right...
> 
> I've writen an application that uses urllib2, urlparse, robotparser and
> some other modules in the battery pack. One day my app failed with an
> urllib2.HTTPError. So I catch that. But then I get a urllib2.URLError, so
> I catch that too. The next day, it encounters a urllib2.HTTPError, then a
> IOError, a socket.timeout, httplib.InvalidURL,...
> 
> How do you program robustly with these modules throwing all those
> different (and sometimes undocumented) exceptions at you?

I do it by not micromanaging things.  Presumably if you plan to catch an 
exception, you have a specific procedure in mind for handling the 
problem.  Maybe a retry, maybe an alternate way of attempting the same 
thing?  Look to the code that you are putting in those except: 
statements (or that you think you want to put in them) to decide what to 
do about this situation.  If each type of exception will be handled in a 
different manner, then you definitely want to identify each type by 
looking at the source or the docs, or doing it empirically.

Most of the time there isn't a whole lot of real "handling" going on in 
an exception handler, but merely something like logging and/or reporting 
it onscreen in a cleaner fashion than a traceback, then failing anyway. 
  This is one reason Java does get it wrong: 95% of exceptions don't 
need and shouldn't have special handling anyway.

Good code should probably have a very small set of real exception 
handling cases, and one or two catchalls at a higher level to avoid 
barfing a traceback at the user.

> A catchall seems like a bad idea, since it also catches AttributeErrors
> and other bugs in the program.

Generally speaking this won't be a problem if you have your catchalls at 
a fairly high level and have proper unit tests for the lower level code 
which is getting called.  You are doing unit testing, aren't you? ;-)

-Peter




More information about the Python-list mailing list