Managing InterruptedException

Question

I have read http://www.ibm.com/developerworks/java/library/j-jtp05236/index.html

I decide to make my lock uncancelable task by

try {
    lockedRecords.wait();
} catch (InterruptedException e) {
    interrupted = true;
}

but is there a need to

} finally {
    if (interrupted) {
        Thread.currentThread().interrupt();
    }
}

The article says that you should call interrupt() to preserve the interrupted status. I'm still very blur, so what if I set .interrupt? what happens next? a bit lost on this.. any input?

What value does it bring to my program? Please kindly explain in layman terms, greatly appreciated :D

score 2 · Accepted Answer · answered Aug 09 '11 at 23:45

What's important here is the code that is not written in the example. The method in the example (getNextTask) could be used in:

while (!Thread.interrupted()) {
   Task task = getNextTask(queue);  
   doSomething(task);
}
System.out.println("The thread was interrupted while processing tasks.");
System.out.println("...stopped processing.");

The while loop above executes forever, unless someone interrupts the thread on which this loop runs.

If the interrupt status is not reset as is done in getNextTask however, when someone tries to interrupt the thread when the thread is in queue.take in getNextTask, then the interrupt is lost and the bit of code I wrote above will never stop looping.

The whole point of the example on the IBM webpage is that you must be very careful when you swallow an interrupt since it might accidentally make a thread impossible to interrupt.

oic but if there is no code in the application that stop on interrupt, we shouldn't be worried about it? — seesee, Aug 10 '11 at 17:00
Well yes... but it's better to set the interrupt anyway because you might reuse your code for something else at some point and it will be very hard to figure out why some thread cannot be interrupted. — toto2, Aug 10 '11 at 20:42

score 0 · Answer 2 · answered Oct 27 '11 at 14:18

Just swallowing the InterruptedException is fine as long as you know that the current thread will terminate after your task is done and returns.

Problems may arise when using some thread pool, like ExecutorService, where usually the threads continue to run after a task has completed, waiting for the next task to come. In this case the pooled thread should be notified it was interrupted so that it can do whatever is appropriate in this situation, e.g. perform a clean shutdown and exit.

Thus, it is good practice and more safe to make sure you restore the interrupted state before returning from your routine.

Managing InterruptedException

2 Answers2