InterruptedException should not be caught and handled with other exceptions

Sometimes methods throw mulitple exceptions including InterruptedException. Consider for example

public void org.eclipse.jface.dialogs.ProgressMonitorDialog.run(boolean, boolean, IRunnableWithProgress) throws InvocationTargetException,
			InterruptedException;

from Jface. This could result in handling both exceptions using a multi-catch:

try {
  diaglog.run(...);
} catch (InvocationTargetException | InterruptedException e) {
  ...
}

Following guidance of rule S2142 handling the InterruptedException could lead to the following code:

try {
  dialog.run(...);
} catch (InvocationTargetException | InterruptedException e) {
  Thread.currentThread().interrupt();
}

However, now the current thread is interrupted even if an exception unrelated to InterruptedException is thrown. This leads to bugs which are difficult to track because code executing at a later time which checks the interrupt flag might stop execution.
Valid handling could look like

try {
  dialog.run(...);
} catch (InvocationTargetException e) {
  ...
} catch (InterruptedException e) {
  Thread.currentThread().interrupt();
}

This rule should be classified as bug because handling any exception the same as InterruptedException is always wrong.

There are no exceptions to this rule: No exception should be handled the same as InterruptedException and error handling for InterruptedException is never the same as for any other exception.

Hello @oliver
thanks for raising this topic.
Let me try to rephrase a bit to make sure I have it right.

  1. You are promoting here the addition of a new rule in order to prevent the handling of any exception with InterruptedException
  2. You interpret S2142 as possibly misleading because you believe it may lead to a handling of an InterruptedException as part of a multi-catch statement.

Is that correct?
Although I see some merit with point 1 and your rule suggestion, I have some doubts about the 2nd one. S2142 does not mentions this corner case and I don’t believe it should prevent any developer from applying some common sense when writing his Exception handling.

Would you want to attract more interest from the Java developers community, I believe you should rephrase your post as a clearer rule suggestion.
Linking the good practice enforcement that you are proposing to some wrong guidance given by the S2142 rule documentation is a debatable point that is preventing your idea to be understood and weighted by the Java developers I believe.
WDYT?

Best.
Sylvain