On 05/14/09 17:15, Tim Quinn wrote:
> Scott Oaks wrote:
>>
>> I was just going to bite my tongue, but I will argue that the finally
>> clause is far, far better. Exception chaining is a frustrating thing;
>> it makes root cause analysis very difficult. I definitely agree that
>> in most cases it is a mistake...
> What do you mean by "chaining?" By "chaining" I meant throwing a new
> exception with the caught one as the cause of the new one. Long chains
> of this type make for long stack traces, to be sure, but they also tell
> a great deal about the root error and the context in which it occurred.
>
> Now, if by "chaining" you meant catching an exception and then throwing
> a new one without bringing the original one along as the cause of the
> new one, then that's what I referred to as "masking" which is deadly.
It's true; there are two kinds of things here, and I am conflating them.
My bad.
But still, even properly chained exceptions make root cause analysis
harder, particularly in the appserver because it will eventually limit
the length of the stack traces. And as you say, doing it wrong is quite
deadly.
>> What caused my to put my $.02 after all? I'm just looking right now at
>> some appserver code where something threw a NullPointerException,
>> which was wrapped in a JDOFatalInternalException, which was wrapped in
>> an EJBException, which was wrapped in a
>> TransactionRolledBackException, which was wrapped into another
>> EJBException. It should be trivial to track down the NPE, but almost
>> all information about it is lost (except for the location where it was
>> caught, which is something I guess...).
> Was the cause of each exception set to the next lower-level one? Or
> (shudder) was just the message of each lower-level one captured and set
> in each higher-level exception?
> Or did I miss your point?
Well, the JDOFatalInternalException in this case doesn't chain properly,
which I didn't realize until just now when I went to look at it: it is
constructed with the other exception as an argument, but its
implementation doesn't call the correct superclass constructor for that
to work. So I was incorrectly blaming the fact that I don't see any
information on the root cause on the JDK giving up printing stack traces
after it had dumped a few hundred lines of output. [A few hundred
lines...bad enough!]
But still: I am much in favor of using finally to close things and
passing exceptions up the stack than just wrapping one kind of exception
within another -- and particularly wrapping one runtime exception in
another runtime exception, which is another annoying thing I see all the
time.
-Scott
>
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>