Best way to handle InterruptedException

Question

I am using Thread.sleep(10000); hence i need to handle InterruptedException. I can call Thread.currentThread.interrupt () and then throw the exception to calling class or i can directly throw it to calling class or is there any better way to handle it ?

Answer 1

If you have a dedicated thread that is looping and polling, that sounds to me like something that needs to be terminated when the program ends; unless it is a daemon thread (implying you are happy with it going away with no chance to cleanup or close resources) it needs to be able to handle interruption. Using WatchService seems like a good idea, but the code that uses the WatchService still has to know how to handle interruption.

If you are writing a Runnable or Callable that sleeps, you can use the InterruptedException to exit whatever looping you're doing, or you can catch the exception and restore the interrupt flag so that the next check of the interrupt flag (using Thread.currentThread().isInterrupted()) can see that the thread has been interrupted:

while(!Thread.currentThread().isInterrupted()){  
   //do something   
   try{  
     Thread.sleep(5000);    
   } catch(InterruptedException e){  
        Thread.currentThread().interrupt();
   }
}

Alternatively you can use the InterruptedException to get out of the loop:

try {
    while (!Thread.currentThread().isInterrupted()) {
        // do something
        Thread.sleep(5000);
    }
} catch (InterruptedException e) {
    // flag value is not used here
    Thread.currentThread().interrupt(); 
}

If you are developing an object that you expect to nest inside other objects, then throw the exception and add it to the method signature. As an example look at the API doc for classes in the java.util.concurrent packages, like BlockingQueue, see how methods like put and offer throw InterruptedException. When objects made for concurrency are composed together they need to cooperate (and make sure they don't lose track of interrupted status) in order to make sure that they can clean up and terminate in a responsive manner.

Answer 2

In most normal code, you shouldn't use sleep. There is often a better way to do what you want.

I can call Thread.currentThread.interrupt ()

This is useful if you want to continue as normal, but without waiting.

and then throw the exception to calling class

OR I would throw an exception, you can wrap the exception with one of your choice.

or i can directly throw it to calling class

You might as well not catch in this case.

or is there any better way to handle it ?

It depends on why you expect the thread to be interrupted. if I don't expect an interrupt ever, I wrap it with an AssertionError

Answer 3

Generally, rethrow if you can, or set the interruption flag if you cannot rethrow.

A good article on this is http://www.ibm.com/developerworks/library/j-jtp05236/

from which this is the most relevant excerpt would be:

When a blocking method detects interruption and throws InterruptedException, it clears the interrupted status. If you catch InterruptedException but cannot rethrow it, you should preserve evidence that the interruption occurred so that code higher up on the call stack can learn of the interruption and respond to it if it wants to.

Answer 4

I am using Thread.sleep(10000); hence i need to handle InterruptedException.

Not necessarily. There are smart ways to handle InterruptedException, and there are stupid ways. If your thread will never actually be interrupted, then does it really matter which way you pick?

Of course, if you think that your code might ever be re-used, or if you think that other programmers are going to read it, then you might want to go with the smart way. If you want to practice good coding habits, you might want to go with the smart way (lots of examples out there, just waiting to be found with a google search).

But sometimes we just want to write a quick hack, that we're going to use once and then throw away...