commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Rall <>
Subject Re: DBCP/LANG
Date Tue, 13 Aug 2002 18:11:06 GMT writes:

> On Sun, 11 Aug 2002, Henri Yandell wrote:
> > So you mean an ExceptionUtils style thing that will take 'getCause' as a
> > special method name, use reflection to see if it's there, and assumed a
> > tree of Exceptions via getCause?
> Actually there are 2 patterns - getCause() is used in 99% of 
> cases, there is also 'detail' public field in RemoteException.
> But yes, that's what I meant. 
> > Sounds good.
> > 
> > ExceptionUtils.toNested(Exception);NestableException ? ;)
> No. Why would you do that ??
> Throwable ExceptionUtils.getCause(Throwable);
> seems right the right signature.

I agree, and have implemented such a class (with unit tests) and
committed it to the exception package of [lang].  I added two methods,
one to get the immediate cause, and another to ferret out the root
cause (after walking the exception tree).  Costin, Henri, when you
have a moment, any review would be appreciated.

Note that I didn't implement RMI's "detail" instance attribute,
partially because I think it's a poor pattern, and partially because
I'm not a big fan of RMI (I prefer a SPOF-less MOM approach).

> For NestException - can you give me any benefit or functionaity that 
> can't be provided for generic Throwables, using getCause() ? 

Another benefit includes stack trace joining (i.e. trace of the casual
exception is appended to the trace of the primary exception).  This
functionality might be useful to refactor into the new ExceptionUtils

Daniel Rall <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message