Why InterruptedException is Checked
Fast recall
Quick revision
Core answer
InterruptedException is checked so code calling interruptible blocking methods must decide what interruption means for that operation. If a method can propagate it, let it propagate. If code catches it but cannot rethrow it, it normally restores the interrupt status and stops or returns according to its cancellation policy. Interruption is a request, not a forced command to terminate.Whether you understand interruption as a cooperative cancellation signal and the correct handling pattern
Swallowing InterruptedException with an empty catch, destroying the interrupt status
Explain that catching it clears the interrupt flag, so you must restore it (or rethrow) so callers can also react
Interview-ready guide
Interview answer
InterruptedException is checked, so a caller of an interruptible blocking method must make an explicit decision about the interruption. Methods such as sleep, wait, join, and blocking-queue operations can throw it when interruption is observed.
Interruption is a cooperative request, not a forced thread stop. For example, a worker whose method already declares throws InterruptedException can let it propagate to its task boundary. If a method cannot propagate it, a common policy is to call Thread.currentThread().interrupt() to restore the status and then return or stop its loop. The exact action belongs to the task's cancellation contract; blindly swallowing it makes cancellation unreliable.
Why InterruptedException is Checked
Direct Answer
InterruptedException is checked so code calling interruptible blocking methods must decide what interruption means for that operation. If a method can propagate it, let it propagate. If code catches it but cannot rethrow it, it normally restores the interrupt status and stops or returns according to its cancellation policy. Interruption is a request, not a forced command to terminate.
Common Mistakes & Pitfalls
- Empty catch: loses the interruption request and can make shutdown hang.
- Always restoring and continuing: restoring is useful only with a policy that will observe it; do not keep retrying the same blocking call forever.
- Treating
interrupt()as a kill: it sets a status and causes certain blocking operations to react; the task still cooperates. - Converting it to a generic exception without the cause: this hides the cancellation signal and diagnostic trail.
- Assuming one response fits every API: propagate when possible; otherwise follow the owner-defined cancellation policy.
Check your understanding
Answer these without looking back at the article.
- What is the interrupted flag on a thread?
- What is the difference between Thread.interrupted() and Thread.isInterrupted()?
- Why is swallowing InterruptedException considered a bug?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.