Re: BUG org.postgresql.Driver.connect() distorts InterruptedException

Am 13.08.2013 um 19:15 schrieb Florent Guillaume <fg@nuxeo.com>:

> On Tue, Aug 13, 2013 at 5:41 PM, Andreas Rudolph
> <andreas.rudolph@spontech-spine.com> wrote:
>> Am 13.08.2013 um 12:46 schrieb Florent Guillaume <fg@nuxeo.com>:
>>> InterruptedException should be rewrapped only very carefully. When you
>>> receive InterruptedException it means "this thread must die", so if
>>> you have to rethrow something else due signature issues to you should
>>> rethrow something that nobody will catch and swallow. I'd rethrow a
>>> bare RuntimeException in need be.
>> I think it's acceptable to wrap it in another checked exception if that exception signals that the request that has
beeninterrupted has failed because of interruption. Of course I agree that it would be better if a method that could
failin such a way would specify InterruptedException in its throws clause. But if you have to deal with frameworks that
aredesigned differently, for example JDBC, wrapping it as described seems to be a reasonable option. 
>
> If you wrap it in a PSQLException then a JDBC connection pool could
> take that as meaning that this connection has problems and should be
> removed from the pool, but it won't check or propagate the interrupt,
> and won't check the exception's cause either. Very few frameworks do.
> That's why it's important that if you have to rewrap, you rewrap in an
> exception that nobody risks catching without knowing that there's an
> underlying interruption.
In my bug report I was talking about another situation: The implementation of org.postgresql.Driver.connect(String url,
Propertiesinfo) does NOT leave any evidence that the calling thread (i.e. client code) has been interrupted while
waitingfor a Connection to be returned. In this situation there is no Connection at all, yet, that could be reused or
removedfrom a pool. 
(I guess instead a pool implementation would call Driver.connect() by itself to obtain a connection for the first time,
thatis the pool implementation would be a client of the Driver class.) 

Even if someone agrees with your statement that receiving an InterruptedException (always) means "this thread must die"
thisDOES NOT necessarily mean that it must die _immediately_! On the contrary it might need to do some clean-up,
releaseresources etc. Throwing an unchecked exception in the hope that it would not be caught is of no help in this
case.

The decision what an interrupt should mean to the thread in question, that is the thread that has been created by
clientcode and which executes Driver.connect(), is up to the programmer of the client code. Therefore I was asking to
improveinteroperability by allowing the client code to detect that the thread that executes it has been interrupted. 

Regarding exception handling with Driver.connect():
Clients must catch the _checked_ SQLException. If client code has caught this exception this is a clear indication that
no(usable) Connection object could have been returned otherwise. I can't see any evidence in your reasoning why
supplyingan InterruptedException as a cause of a checked exception would do any harm here. It just reveals the fact
thatthe connection could not be established because the requesting thread has been interrupted. 

Could you please tell why doing _both_, suppling a cause _and_ setting the interrupted flag again, in the case of
Driver.connect()seems unsound to you?