On Mon, 30 Apr 2001, Jeffrey W. Baker wrote:
> I have learned that errors from down in the call stack are very rarely
> conditionally recoverable. If I call obj->method(), and it throws an
> exception, there are few situations where the cause of the exception
> matters at all. In most cases I will just not handle the exception, and
> it will bubble up. In some cases I might want to log. In others I might
> want to retry, or try plan B. But, very rarely do I want to branch on the
> type of exception. Right now I cannot in fact think of any program I have
> written that branches on the type of exception. Java encourages this with
> multiple catch blocks, but I think it is stupid and anyway the catcher
> usually is not the primary source of knowledge about what the hell
> happened. Think of it: the called program had to make a decision about
> what exception to throw, and now the caller is trying to decode that
> exception. I believe that decisions should be made at the place in the
> program that has the most relevant information about the decision. If you
> try to encode information into the exception object, you are encouraging
> some other part of the program to make a less-informed opinion.
[snip]
Right, this is standard exceptions stuff. You should never catch
exceptions anywhere but your main() (or in mod_perl's case,
handler()) routine, unless you have to, and when you have to be *very*
careful about what you're doing, and why you're doing it.
I'll try and cover this in my talk.
--
<Matt/>
/|| ** Founder and CTO ** ** http://axkit.com/ **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
