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

I'm inclined to go with Florent's suggestions here. Throwing a SQL
exception here would go unnoticed.

Dave Cramer

dave.cramer(at)credativ(dot)ca
http://www.credativ.ca

On Tue, Aug 13, 2013 at 1:15 PM, Florent Guillaume <fg(at)nuxeo(dot)com> wrote:

> On Tue, Aug 13, 2013 at 5:41 PM, Andreas Rudolph
> <andreas(dot)rudolph(at)spontech-spine(dot)com> wrote:
> > Am 13.08.2013 um 12:46 schrieb Florent Guillaume <fg(at)nuxeo(dot)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 been interrupted has failed
> because of interruption. Of course I agree that it would be better if a
> method that could fail in such a way would specify InterruptedException in
> its throws clause. But if you have to deal with frameworks that are
> designed 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.
>
> Florent
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
>