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