views:

85

answers:

4

What is the difference between the following ways of handling InterruptedException? What is the best way to do it.

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

OR

try{...}
catch(InterruptedException e)
{throw new RuntimeException(e);}

EDIT: I'd like to also know in which scenarios are these two used.

A: 

It depends on what situation it has been thrown.

If you can perform some action to get out of it. than go for catch and handle it there.

If you are writing some apis and want to throw it to calling method then use throw in catch

org.life.java
+5  A: 

Simply re-throwing a checked exception in the form of a runtime-exception is a bad habbit. So for the scenarios in which the second approach is desirable, I'd say never.

In the particular case of InterruptedException I would say it depends on the specific situation. Do you care about interrupts?

Examples:

  • Usually, when I perform a Thread.sleep I care little about interrupts, and I just ignore the exception.

  • If I'm doing some blocking read etc, it's a completely different story. I may for instance redo the read if I was interrupted, or I may want to try to close the stream.

A third option is to rethrow the (checked) InterruptedException. In some cases however (when you're for instance implementing an interface method, that is not declared to throw this exception) you should go for your first approach.

Here is a good article on the subject: http://www.ibm.com/developerworks/java/library/j-jtp05236.html

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. This task is accomplished by calling interrupt() to "reinterrupt" the current thread, as shown in Listing 3.

aioobe
@aioobe thanks!
iJeeves
What is the problem with the second method?
Mahatma
Deciding if an exception should extend RuntimeException or not is an important and "active" decision. In the second method, you sort of say, "I know better than the guy that wrote the class.". Clearly a checked exception is something that should not go below the radar, here you force it to.
aioobe
+3  A: 

What are you trying to do?

The InterruptedException is thrown when a thread is waiting or sleeping and another thread interrupts it using the interrupt method in class Thread. So if you catch this exception, it means that the thread has been interrupted. Usually there is no point in calling Thread.currentThread().interrupt(); again, unless you want to check the "interrupted" status of the thread from somewhere else.

Regarding your other option of throwing a RuntimeException, it does not seem a very wise thing to do (who will catch this? how will it be handled?) but it is difficult to tell more without additional information.

Grodriguez
Calling `Thread.currentThread().interrupt()` sets the interrupted flag (again), which is useful indeed if we want to ensure that the interrupt gets noticed and processed on a higher level.
Péter Török
@Péter: I was just updating the answer to mention this. Thanks.
Grodriguez
+2  A: 

As it happens i was just reading about this this morning on my way to work in Java Concurrency In Practise by Brian Goetz. Basically he says you should do one of two things

  1. Propogate the InteruptException - Declare your method to throw the checked InteruptException so that your caller has to deal with it.

  2. Restore the Interupt - Sometimes you cannot throw InterruptException. In these cases you should catch the InteruptException and restore the interupt status by calling the interupt() method on the currentThread so the code higher up the call stack can see that an interupt was issued.

mR_fr0g