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.
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
