Identifying exceptions that can be raised

[Jim Hefferon]

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
do.

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 (the xml
parser is vague about what it could raise, and although the dB is a
bit better, it is not always clear what an exception means or under
what condidtions it could be raised).  I'm left with the feeling that
for any amount of testing that I do (and I've found cgi hard to
automatically test), there is always another exception lurking out
there.  I have a great deal of difficulty achieving the feeling that I
am consistently returning a sensible error screen to the user.

I've tried Java, and found it a slog, but for some programs knowing
which exceptions could be raised would be a comfort.

> All that said, you do sometimes find yourself pondering
> what exceptions a given function might raise and which
> you *do* want to handle properly.  It's not always clear,
> and unfortunately short of examining the source or hoping
> that the author wrote decent documentation, you're out
> of luck.

I second that.

Jim