Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

InterruptedException : what causes it?

Tags:

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?

like image 510
user1050755 Avatar asked Nov 11 '14 01:11

user1050755


People also ask

What causes InterruptedException?

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.

How do I resolve InterruptedException?

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.

Why sleep method throws InterruptedException?

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.

Which of the following methods throw InterruptedException?

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 .


1 Answers

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 as ThreadGroup.interrupt.

See the official tutorial on interrupts for some more info as well. Specifically:

A thread sends an interrupt by invoking interrupt on the Thread 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 method Thread.interrupted, interrupt status is cleared. The non-static isInterrupted 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 invoking interrupt.

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.

like image 129
Jason C Avatar answered Oct 28 '22 01:10

Jason C