https://issues.apache.org/bugzilla/show_bug.cgi?id=52066
--- Comment #2 from Alexander Pogrebnyak <alex-pub.apache-...@reflexion.net>
2011-10-26 14:31:26 UTC ---
(In reply to comment #1)
There may be quite a few clients down the call chain that require the knowledge
that interrupt is in progress, and clearing of the interrupted flag destroys
this knowledge.
It is semantically very similar to the olden days practice of swallowing
exception in the library code, e.g.
try
{
doSomethingRisky( );
}
catch ( Throwable ex )
{
}
Plus, it's not OK for the general user of the library to depend on your
specific wrapper of InterruptedException into the SQLException. A user can
switch to another implementation of connection pool and that particular library
reporting policy may not be the same as this library's.
The right thing to do is to preserve the thread interruption status by calling
Thread.currentThread( ).interrupt( ), and let the client code deal with it.
BTW, setting InterruptedException as a cause of SQLException is a GOOD THING, I
don't want you to change that.
--
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
