Re: InterruptedException handling

Kenneth P. Turvey wrote:
I used to do a lot of programming in C (still do sometimes) and when a call was made to sleep there were a number of reasons that it might return early that had little to do with the program being written. It was typical to wrap these calls in a loop so that the program would sleep for the correct amount of time. So when I first moved to Java I would typically do the same thing with an InterruptedException, catching it and looping back to the wait or the sleep or whatever had caused the exception.
The loop is necessary for Object.wait() calls, but InterruptedException is a different beast.

I think this was a mistake. In Java it seems that the only reason a thread would be interrupted is do to a direct call to Thread.interrupt
(). So it seems that the best way to handle this exception if it is unexpected is to let it bubble up through the code like one usually would.
Or, if you are expecting it as a specific type of signaling device (such as "abort your current work")

Of course if the code is designed to do something with an InterruptedException, handling it makes sense, but should it simply be ignored in code that doesn't expect this to happen? This line of reasoning also extends to similar exceptions like the BrokenBarrier exception and others.

Is there any reason to handle InterruptedExceptions as a special case?
Only if you are the owner of the Thread Lifecycle (eg. you have a contract with the part of the code that is likely to call Thread.interrupt())

For example, the exception happens in a Callable that is passed to a ThreadPoolExecutor, you should probably let it propagate. However, if you are implementing ThreadPoolExecutor, your worker threads may have special handling for that exception.


--
Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
.

Relevant Pages

  • Re: Threading design question
    ... basically I'm using the Interrupted exception to break out of the ... When the sleep expires, it does ... not throw the InterruptedException; ... process what's in th DB immediately, which is still normal processing: ...
    (comp.lang.java.programmer)
  • Re: InterruptedException handling
    ... call was made to sleep there were a number of reasons that it might ... was typical to wrap these calls in a loop so that the program would sleep ... before x ms have elapsed even if no InterruptedException was thrown ... doesn't say anything explicit in this sense. ...
    (comp.lang.java.programmer)
  • Re: How to call Thread.sleep() or Thread.yield() without enclosing try/catch block ?
    ... > "the sleepmethod can throw a checked InterruptedException, ... > your're forced to acknowledge the exception with a handle or declare. ... > Typically, you just wrap each call to sleep in a try/catch, ... ... > couldn't be overriden to throw InterruptedException. ...
    (comp.lang.java.help)
  • InterruptedException handling
    ... was typical to wrap these calls in a loop so that the program would sleep ... So it seems that the best way to handle this exception if it is ... InterruptedException, handling it makes sense, but should it simply be ... Is there any reason to handle InterruptedExceptions as a special case? ...
    (comp.lang.java.programmer)
  • Re: Not using exceptions only for exceptional conditions
    ... I always have agreed that exception shouldn't be used for flow control, ... Now, I see that the first form is better for many reasons, but if the ... Exceptions are realy realy slow for building stack ...
    (comp.lang.java.programmer)