commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Botelho, Mauro" <>
Subject RE: [Pool] Use of Exception in API
Date Mon, 27 Sep 2004 19:07:15 GMT
What I think he's talking about is having a Pools exception, e.g. org.apache.pools.PoolException
that would nest the exception thrown.

I think this is one of the "Effective Java" recommendations, but I don't have the book with
me here to verify...


-----Original Message-----
From: Rodney Waldhoff []
Sent: Monday, September 27, 2004 2:36 PM
To: Jakarta Commons Users List;
Subject: Re: [Pool] Use of Exception in API

On Mon, 20 Sep 2004, Tom van den Berge wrote:

> Hi,

Hi Tom.

> Hi recently started using the pool API, and I think it's a very useful API.
> However I noticed the frequent "throws Exception" declarations, which is
> generally bad practice. Many of the core methods in the interfaces declare
> it, so automatically all implementations are using it, too.

It is not possible for the pool framework to know what kind of exceptions 
might be encountered in the underlying implementation (e.g., in 
createObject of PoolableObjectFactory).  Hence a generic Exception type is 
used.   Consider, for example, the SQLException thrown by DBCP.

Alternatives might include swallowing the exception quietly (much worse) 
or tunneling the exception in a RuntimeException (arguably no better than 

Fundamentally this is a drawback to a strongly typed, checked exception 
system.  I don't see how "replacing Exception with more specific 
exceptions" could possibly work in the general case.

  - R
> One example is the borrowObject method from ObjectPool. The implementing
> class GenericObjectPool calls a couple of methods from
> PoolableObjectFactory, which also throw Exception, and the method itself
> also throws an Exception.
> Are there any plans scheduled for refactoring these issues throughout the
> API?
> Since the code is fairly small in size and compact, it shouldn't be too
> much effort, and the code will improve greatly. Backward compatibility is
> not an issue since you would typically replace the Exceptions with more
> specific exceptions.
> Regards,
> Tom

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

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

View raw message