Which code can swallow interruptedException?

Question

I read concurency in practice. Now I want to understand how to handle InterrruptedException

Advices from book:

- Propagate the exception (possibly after some task-specific cleanup), making your method an interruptible blocking method, too; or
- Restore the interruption status so that code higher up on the call stack can deal with it.
- Only code that implements a thread's interruption policy may swallow an interruption request. General-purpose task and library code should never swallow interruption requests.

First two statements are clear for me but I don't understand third. Can you clarify this? Providing example will preferably.

update(thanks Shubham for the link )

The one time it is acceptable to swallow an interrupt is when you know the thread is about to exit. This scenario only occurs when the class calling the interruptible method is part of a Thread, not a Runnable or general-purpose library code, as illustrated in Listing 5. It creates a thread that enumerates prime numbers until it is interrupted and allows the thread to exit upon interruption. The prime-seeking loop checks for interruption in two places: once by polling the isInterrupted() method in the header of the while loop and once when it calls the blocking BlockingQueue.put() method.

public class PrimeProducer extends Thread {
    private final BlockingQueue<BigInteger> queue;

    PrimeProducer(BlockingQueue<BigInteger> queue) {
        this.queue = queue;
    }

    public void run() {
        try {
            BigInteger p = BigInteger.ONE;
            while (!Thread.currentThread().isInterrupted())
                queue.put(p = p.nextProbablePrime());
        } catch (InterruptedException consumed) {
            /* Allow thread to exit */
        }
    }

    public void cancel() { interrupt(); }
}

I don't understand the bolded text now.

Decigram

If non core code were to swallow an interruption request, then anyone else depending on that signal could be thrown off, and it isn't desirable for that to happen. This would be my guess. – Inexcusable

And here is a good read ibm.com/developerworks/java/library/j-jtp05236/index.html – Conjunct

lower level of code should propogate such exceptions to let the higher level code manage them. Refer my answer below, hopefully it will be of help. – Linguini

I don't think that the PrimeProducer is a good example of code which should swallow interruption. Whilst you might expect the code to be invoked directly as a thread, there is no reason only to use it like this: you could just use an instance of it anywhere that a Runnable is to be used. As such, you don't know for certain that the thread is about to exit. The interrupted flag should be restored there; and where's the harm in doing so? It doesn't affect the "direct thread" use case, and fixes the "indirect" usage. – Relationship

@Andy, Brian Goetz - article author – Decigram

@Decigram and that means I shouldn't think about it critically? I am just stating an example of how this would appear not to work. – Relationship

Answer 1

ExecutorService would be an example of the third statement.

This coordinates the execution of multiple runnables(/callables) on the same "actual" thread.

If one runnable is interrupted whilst being executed, that interruption should not affect execution of subsequent runnables.

So, ExecutorService should swallow the interruption, having dealt with it appropriately from the perspective of the interrupted runnable, in order to allow reuse of the thread for the next runnable.

Relationship

Answer 2

Short answer: If you can deal with the situation, it is allowed to swallow it.

The interrupted exception occurs when the process occurring in that parallel thread was cancelled, or well, interrupted. So if you are the only one interested in that fact, and you can deal with the situation of having that thread "dead", then you can swallow it.

That is perfectly possible in real life examples. The strategy depends on each situation.

Neon

Answer 3

Suppose we write a utility code and there is some clinet code dependent upon our code. If an InterruptedException occurs, it should not be consumed in the utility method (in a try block), it should be thrown and also as InterruptedException clears the interrupt flag, it must be set again to true by invoking interrupt method.

Its the core code which needs to take care of the decision to be taken upon occurrence of an InterruptedException [update] This core code may depend upon the interrupt flag or the InterruptedException to terminate a loop, end thread's execution or any other decision.

Moreover utility or library are the low level code which is invoked from higer level client code. Low level should ideally propogate such exception to let the higher level code manage it.

Linguini