There are interesting questions and answers regarding Java's InterruptedException, for example The Cause of InterruptedException and Handling InterruptedException in Java. However, none of them tells me about the possible sources of InterruptedException.
What about OS signals like SIGTERM, SIGQUIT, SIGINT? Does pressing CTRL-C on the command line produce an InterruptedException? What else?
Thrown when a thread is waiting, sleeping, or otherwise occupied, and the thread is interrupted, either before or during the activity. Occasionally a method may wish to test whether the current thread has been interrupted, and if so, to immediately throw this exception.
In thread-related code, you will often need to handle an InterruptedException . There are two common ways of handling it: just throw the exception up to the caller (perhaps after doing some clean up) call the interrupt method on the current thread.
sleep() method throws InterruptedException if a thread in sleep is interrupted by other threads. InterruptedException is a checked type of exception. That means, “Thread. sleep()” statement must be enclosed within try-catch blocks or it must be specified with throws clause.
A blocking method should include throws InterruptedException otherwise is a normal method. A blocking method can compromise responsiveness because it can be hard to predict when it will complete that's why it needs throws InterruptedException .
None of the things you list produce an InterruptedException
.
The only thing that can interrupt a thread is a call to Thread#interrupt()
. The JLS is relatively clear on the matter, from section 17.2.3:
17.2.3 Interruptions
Interruption actions occur upon invocation of
Thread.interrupt
, as well as methods defined to invoke it in turn, such asThreadGroup.interrupt
.
See the official tutorial on interrupts for some more info as well. Specifically:
A thread sends an interrupt by invoking
interrupt
on theThread
object for the thread to be interrupted. For the interrupt mechanism to work correctly, the interrupted thread must support its own interruption....
The interrupt mechanism is implemented using an internal flag known as the interrupt status. Invoking
Thread.interrupt
sets this flag. When a thread checks for an interrupt by invoking the static methodThread.interrupted
, interrupt status is cleared. The non-staticisInterrupted
method, which is used by one thread to query the interrupt status of another, does not change the interrupt status flag.By convention, any method that exits by throwing an
InterruptedException
clears interrupt status when it does so. However, it's always possible that interrupt status will immediately be set again, by another thread invokinginterrupt
.
The implication is that it is an explicit flag settable only by calling interrupt()
, rather than triggered by other unknown external events. This is further implied by the description of the exception in various methods that throw it, for example (emphasis mine):
InterruptedException
- if any thread has interrupted the current thread. The interrupted status of the current thread is cleared when this exception is thrown.
The purpose of the interrupt system in general is to provide a common, well-defined framework for allowing threads to interrupt tasks (potentially time-consuming ones) in other threads. While you could implement similar functionality with explicit logic in your own application, having this well-defined mechanism allows independent classes (e.g. the JDK, other third-party code, other independent classes in your own code) to provide this functionality in a consistent way.
The many notes and "warnings" you see about handling InterruptedException
aren't meant to imply that they can be thrown completely spontaneously, they are meant to encourage well-designed objects that can be used in contexts that are not known yet, where interrupt()
would be presumed to work (so really, you do want to assume they can be thrown spontaneously if you are creating reusable objects that will be robust in future situations - i.e. you're never guaranteed that your code won't be some day used by somebody who expects interrupts to work).
For quick one-off projects you don't really need to worry about special handling for these exceptions as long as you know for certain that you aren't calling interrupt()
and aren't calling something that can call interrupt()
, but be aware of the implications of that in the long run, especially if you end up reusing that code in other contexts.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With