Identifying exceptions that can be raised

Steve Holden steve at
Tue Nov 23 14:22:48 CET 2004

Peter Hansen wrote:

> Jim Hefferon wrote:
>> Peter Hansen <peter at> wrote ..
>>> The usual approach is to have a caller catch exceptions
>>> *which it is capable of dealing with appropriately*, and
>>> ignore others.  In some cases it's necessary to have a
>>> "generic" exception handler, such as at the top level of
>>> a thread, to catch and log all exceptions, but that's
>>> relatively rare.
>> I wonder if perhaps you don't write different kinds of programs than I
>> do.
> I certainly do.  I don't, for example, ever do CGI...
>> For instance, I have a cgi program.  One routine will get an id from a
>> httpd parameter, use it to reach into a database and fetch some xml,
>> and then pull information out of the xml for display.  That I can
>> tell, there are about 100 exceptions that could be raised ...
> ....but were I faced with this situation, I would follow my
> above advice about "in some cases it's necessary...".  This
> is exactly such a situation.  I would always wrap such a
> program** at the top level with a generic exception handler
> and a call to traceback.format_exception() (or whatever it's
> called), turning any errors into visible results, or at
> the very least logging them somewhere for analysis.
Such as is provided by the line

import cgitb; cgitb.enable()

for example.

> ** I don't think of CGI calls as independent _programs_, mind
> you, any more than I think of individual threads as programs,
> but I'm not sure this is affecting my opinion here vis-a-vis
> exception handling.
> -Peter

I think some people just deal with uncertainty better than others. Java 
is indeed a slog, and being forced to write exception handlers for 
errors I never expect to occur and was quite happy to see my program 
fail under was one of the least attractive things about it.

no-more-java-for-me-ly y'rs  - steve
Holden Web LLC +1 800 494 3119

More information about the Python-list mailing list