Identifying exceptions that can be raised
steve at holdenweb.com
Tue Nov 23 14:22:48 CET 2004
Peter Hansen wrote:
> Jim Hefferon wrote:
>> Peter Hansen <peter at engcorp.com> 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
> 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()
> ** 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.
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