Handling InterruptedException in Java

Question

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

User · Answer

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

Propagate the InterruptedException - Declare your method to throw the checked InterruptedException so that your caller has to deal with it.
Restore the Interrupt - Sometimes you cannot throw InterruptedException. In these cases you should catch the InterruptedException and restore the interrupt status by calling the interrupt() method on the currentThread so the code higher up the call stack can see that an interrupt was issued, and quickly return from the method. Note: this is only applicable when your method has "try" or "best effort" semantics, i. e. nothing critical would happen if the method doesn't accomplish its goal. For example, log() or sendMetric() may be such method, or boolean tryTransferMoney(), but not void transferMoney(). See here for more details.
Ignore the interruption within method, but restore the status upon exit - e. g. via Guava's Uninterruptibles. Uninterruptibles take over the boilerplate code like in the Noncancelable Task example in JCIP § 7.1.3.

User · Answer

I just wanted to add one last option to what most people and articles mention  As mR fr0g has stated  it s important to handle the interrupt correctly either by    Propagating the InterruptException Restore Interrupt state on Thread   Or additionally    Custom handling of Interrupt   There is nothing wrong with handling the interrupt in a custom way depending on your circumstances  As an interrupt is a request for termination  as opposed to a forceful command  it is perfectly valid to complete additional work to allow the application to handle the request gracefully  For example  if a Thread is Sleeping  waiting on IO or a hardware response  when it receives the Interrupt  then it is perfectly valid to gracefully close any connections before terminating the thread   I highly recommend understanding the topic  but this article is a good source of information  http   www ibm com developerworks java library j-jtp05236

User · Answer

What is the difference between the following ways of handling InterruptedException  What is the best way to do it    You ve probably come to ask this question because you ve called a method that throws InterruptedException   First of all  you should see throws InterruptedException for what it is  A part of the method signature and a possible outcome of calling the method you re calling  So start by embracing the fact that an InterruptedException is a perfectly valid result of the method call   Now  if the method you re calling throws such exception  what should your method do  You can figure out the answer by thinking about the following   Does it make sense for the method you are implementing to throw an InterruptedException  Put differently  is an InterruptedException a sensible outcome when calling your method    If yes  then throws InterruptedException should be part of your method signature  and you should let the exception propagate  i e  don t catch it at all       Example  Your method waits for a value from the network to finish the computation and return a result  If the blocking network call throws an InterruptedException your method can not finish computation in a normal way  You let the InterruptedException propagate   int computeSum Server server  throws InterruptedException          Any InterruptedException thrown below is propagated     int a   server getValueA        int b   server getValueB        return a   b      If no  then you should not declare your method with throws InterruptedException and you should  must   catch the exception  Now two things are important to keep in mind in this situation    Someone interrupted your thread  That someone is probably eager to cancel the operation  terminate the program gracefully  or whatever  You should be polite to that someone and return from your method without further ado  Even though your method can manage to produce a sensible return value in case of an InterruptedException the fact that the thread has been interrupted may still be of importance  In particular  the code that calls your method may be interested in whether an interruption occurred during execution of your method  You should therefore log the fact an interruption took place by setting the interrupted flag  Thread currentThread   interrupt        Example  The user has asked to print a sum of two values  Printing  Failed to compute sum  is acceptable if the sum can t be computed  and much better than letting the program crash with a stack trace due to an InterruptedException   In other words  it does not make sense to declare this method with throws InterruptedException   void printSum Server server         try            int sum   computeSum server            System out println  Sum      sum          catch  InterruptedException e             Thread currentThread   interrupt        set interrupt flag          System out println  Failed to compute sum                 By now it should be clear that just doing throw new RuntimeException e  is a bad idea  It isn t very polite to the caller  You could invent a new runtime exception but the root cause  someone wants the thread to stop execution  might get lost   Other examples      Implementing Runnable  As you may have discovered  the signature of Runnable run does not allow for rethrowing InterruptedExceptions  Well  you signed up on implementing Runnable  which means that you signed up to deal with possible InterruptedExceptions  Either choose a different interface  such as Callable  or follow the second approach above     nbsp      Calling Thread sleep  You re attempting to read a file and the spec says you should try 10 times with 1 second in between  You call Thread sleep 1000   So  you need to deal with InterruptedException  For a method such as tryToReadFile it makes perfect sense to say   If I m interrupted  I can t complete my action of trying to read the file   In other words  it makes perfect sense for the method to throw InterruptedExceptions   String tryToReadFile File f  throws InterruptedException       for  int i   0  i  lt  10  i              if  f exists                return readFile f           Thread sleep 1000             return null         This post has been rewritten as an article here

User · Answer

I would say in some cases it s ok to do nothing  Probably not something you should be doing by default  but in case there should be no way for the interrupt to happen  I m not sure what else to do  probably logging error  but that does not affect program flow     One case would be in case you have a task  blocking  queue  In case you have a daemon Thread handling these tasks and you do not interrupt the Thread by yourself  to my knowledge the jvm does not interrupt daemon threads on jvm shutdown   I see no way for the interrupt to happen  and therefore it could be just ignored   I do know that a daemon thread may be killed by the jvm at any time and therefore are unsuitable in some cases    EDIT  Another case might be guarded blocks  at least based on Oracle s tutorial at  http   docs oracle com javase tutorial essential concurrency guardmeth html

User · Answer

To me the key thing about this is  an InterruptedException is not anything going wrong  it is the thread doing what you told it to do  Therefore rethrowing it wrapped in a RuntimeException makes zero sense    In many cases it makes sense to rethrow an exception wrapped in a RuntimeException when you say  I don t know what went wrong here and I can t do anything to fix it  I just want it to get out of the current processing flow and hit whatever application-wide exception handler I have so it can log it  That s not the case with an InterruptedException  it s just the thread responding to having interrupt   called on it  it s throwing the InterruptedException in order to help cancel the thread s processing in a timely way    So propagate the InterruptedException  or eat it intelligently  meaning at a place where it will have accomplished what it was meant to do  and reset the interrupt flag  Note that the interrupt flag gets cleared when the InterruptedException gets thrown  the assumption the Jdk library developers make is that catching the exception amounts to handling it  so by default the flag is cleared    So definitely the first way is better  the second posted example in the question is not useful unless you don t expect the thread to actually get interrupted  and interrupting it amounts to an error   Here s an answer I wrote describing how interrupts work  with an example  You can see in the example code where it is using the InterruptedException to bail out of a while loop in the Runnable s run method

User · Answer

The correct default choice is add InterruptedException to your throws list   An Interrupt indicates that another thread wishes your thread to end   The reason for this request is not made evident and is entirely contextual  so if you don t have any additional knowledge you should assume it s just a friendly shutdown  and anything that avoids that shutdown is a non-friendly response   Java will not randomly throw InterruptedException s  all advice will not affect your application but I have run into a case where developer s following the  swallow  strategy became very inconvenient   A team had developed a large set of tests and used Thread Sleep a lot   Now we started to run the tests in our CI server  and sometimes due to defects in the code would get stuck into permanent waits   To make the situation worse  when attempting to cancel the CI job it never closed because the Thread Interrupt that was intended to abort the test did not abort the job   We had to login to the box and manually kill the processes   So long story short  if you simply throw the InterruptedException you are matching the default intent that your thread should end   If you can t add InterruptedException to your throw list  I d wrap it in a RuntimeException     There is a very rational argument to be made that InterruptedException should be a RuntimeException itself  since that would encourage a better  default  handling   It s not a RuntimeException only because the designers stuck to a categorical rule that a RuntimeException should represent an error in your code   Since an InterruptedException does not arise directly from an error in your code  it s not   But the reality is that often an InterruptedException arises because there is an error in your code   i e  endless loop  dead-lock   and the Interrupt is some other thread s method for dealing with that error   If you know there is rational cleanup to be done  then do it   If you know a deeper cause for the Interrupt  you can take on more comprehensive handling   So in summary your choices for handling should follow this list    By default  add to throws  If not allowed to add to throws  throw RuntimeException e    Best choice of multiple bad options  Only when you know an explicit cause of the Interrupt  handle as desired  If your handling is local to your method  then reset interrupted by a call to Thread currentThread   interrupt

User · Answer

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

[java] Handling InterruptedException in Java

Examples related to java

Examples related to multithreading

Examples related to exception-handling

Examples related to interrupted-exception