FR: ensure users who catch InterruptedException also call Thread.currentThread().interrupt()
#1043
Comments
|
InterruptedExceptionSwallowed may do what we want, if memory serves it also suggests an instanceof check in the case of: try {
foo(); // throws Exception
} catch (Exception e) {
+ if (e instanceof InterruptedException) {
+ Thread.currentThread().interrupt();
+ }
throw new RuntimeException(e);
} |
|
err, it looks like that hasn't made it into a release quite yet! |
|
The InterruptedExceptionSwallowed only appears to apply to catch blocks that catch a supertype of InterruptedException, not InterruptedException itself, I believe this is because catching InterruptedException describes the choice to reset the interrupted flag, however it's non-obvious that's the case. We should provide a comment to suppress this check along the lines of |
I imagine we'll want to suppress some of these based on location and context.
|
Is there still any intention to implement this? It would be very valuable. |
What happened?
It's easy for people to write code like this with no failures:
Just rethrowing an exception like this is usually wrong because if the user is trying to abort, the calling thread will be unable to detect that an interruption happened and short-circuit.
What did you want to happen?
For the cases where people are re-throwing some unchecked exception, error-prone should suggest:
} catch (InterruptedException e) { + Thread.currentThread().interrupt(); throw new RuntimeException(e); }The text was updated successfully, but these errors were encountered: