commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: DBCP/LANG
Date Sun, 11 Aug 2002 20:37:08 GMT
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.

> > That doesn't mean there is a need for a NestableException base class
> > that projects should use ( i.e. TomcatException extends
> > NestableException).
> So a Commons version has theoretical importance, even if developers won't
> want to extend things very often. I've towed a line similar to yours on
> extension/interfaces/frameworks, but have felt that very simple cases such
> as NestException and Enum were workable.

Again, I don't know what Enum means - I know Enumeration and Iterator, and 
also ResultSet. Is there anything wrong with one of those ?

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

> Extending a NestableException improves the speed of the arbitrary
> exception handling tools. They can check instanceof before the reflection.

Exceptions should be 'exceptional cases', so speed is not that important.
Besides, creating the Streams ( for stack trace manipulation ) is quite 
slow ( in a server env - i.e a lot of objects and buffers get created ), 
and introspection is not that expensive if you do minimal caching. 


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

View raw message