[
http://issues.apache.org/jira/browse/POOL-91?page=comments#action_12456609 ]
Sandy McArthur commented on POOL-91:
------------------------------------
For me it's an issue of usability. I view a pool as a source of reusable
heavyweight objects. If the pool is unable to provide one, then it's a problem
and thus an Exception. If the pool returns null then you have two ways of
expressing a problem and now the client code has to deal with two ways of
identifying a problem.:
try {
SomeObject o = pool.borrowObject();
// do work
} catch (Exception e) {
// abort, the pool couldn't provide an instance
}
versus:
try {
SomeObject o = pool.borrowObject();
if (o == null) {
// abort, the pool couldn't provide an instance
}
// do work
} catch (Exception e) {
// also abort, the pool couldn't provide an instance
}
What initially got me involved with Pool was that I was duplicating code both
in the PoolableObjectFactory and after check the result of pool.borrowObject()
because the pool either didn't do all it could to succeed and only throw an
exception when there was a real problem. The Pool roadmap is a reflection of my
frustrations: http://wiki.apache.org/jakarta-commons/PoolRoadMap
> StackObjectPool.borrowObject infinate loop when makeObject returns null
> -----------------------------------------------------------------------
>
> Key: POOL-91
> URL: http://issues.apache.org/jira/browse/POOL-91
> Project: Commons Pool
> Issue Type: Bug
> Reporter: Sandy McArthur
> Assigned To: Sandy McArthur
>
> StackObjectPool.borrowObject has a infinate loop when makeObject returns null.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
