Question

I’ve read and re-read Java Concurrency in Practice, I’ve read several threads here on the subject, I’ve read the IBM article Dealing with InterruptedException and yet there’s something I’m simply not grasping which I think can be broken down into two questions:

1. If I’m never ever interrupting other threads myself, what can trigger an InterruptedException?

2. If I’m never ever interrupting other threads myself using interrupt() (say because I’m using other means to cancel my working threads, like poison pills and while (!cancelled) style loop [as both explained in JCIP]), what does an InterruptedException then mean? What am I supposed to do upon catching one? Shutdown my app?

Answer 1

The Thread interrupt mechanism is the preferred way to get a (cooperating) thread to respond a request to stop what it is doing. Any thread (including the thread itself I think) could call interrupt() on a Thread.

In practice, the normal use-cases for interrupt() involve some kind of framework or manager telling some worker thread to stop what they are doing. If the worker thread is “interrupt aware” it will notice that it has been interrupted via an exception, or by periodically checking its interrupted flag. On noticing that it has been interrupted, a well-behaved thread would abandon what it is doing and end itself.

Assuming the above use-case, your code is likely to be interrupted if it is run within a Java framework or from some worker thread. And when it is interrupted, your code should abandon what it is doing and cause itself to end by the most appropriate means. Depending on how your code was called, this might be done by returning or by throwing some appropriate exception. But it probably should not call System.exit(). (Your application does not necessarily know why it was interrupted, and it certainly does not know if there are other threads that need to be interrupted by the framework.)

On the other hand, if your code is not designed to run under the control of some framework, you could argue that the InterruptedException is an unexpected exception; i.e. a bug. In that case, you should treat the exception as you would other bugs; e.g. wrap it in an unchecked exception, and catch and log it at the same point you deal with other unexpected unchecked exceptions. (Alternatively, your application could simply ignore the interrupt and continue doing what it was doing.)

---

1) If I’m never ever interrupting other threads myself, what can trigger an InterruptedException?

One example is if your Runnable objects are executed using an ExecutorService and shutdownNow() is called on the service. And in theory, any 3rd-party thread pool or thread management framework could legitimately do something like this.

2) If I’m never ever interrupting other threads myself using interrupt() … what does an InterruptedException then mean? What am I supposed to do upon catching one? Shutdown my app?

You need analyze the codebase to figure out what is making the interrupt() calls and why. Once you have figured that out, you can work out what >>your<< part of the app needs to do.

Until you know why InterruptedException is being thrown, I would advise treating it as a hard error; e.g. print a stacktrace to the log file and shut down the app. (Obviously, that’s not always the right answer … but the point is that this is “a bug”, and it needs to be brought to the attention of the developer / maintainer.)

3) How do I find out who / what is calling interrupt()?

There is no good answer to this. The best I can suggest is to set a breakpoint on the Thread.interrupt() and look at the call stack.