Java: Handling InterruptedException

You probably come because you’ve called a method that throws InterruptedException and need to deal with it somehow.

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?

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.

Another example: 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.

Yet another: 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 < 10; i++) {
        if (f.exists())
            return readFile(f);
        Thread.sleep(1000);
    }
    return null;
}

Comments (4)

I've gone through a bunch of articles on handling InterruptedException and have not found any example which says that an operation should be retried upon InterruptedException. So I assumed all authors, including you, implied that this exception should not be retried.

Is this the case? Does InterruptedException imply cancel/terminate, or can it also imply something else, like retry?

by Abhishek Agrawal | 
Reply

An interrupt means that someone wants the thread to bail out from its currently blocking operation. It's indeed common that this is part of some higher level "abort", like user tries to terminate the application, but this is arguably not always the case.

Ultimately it is only the thread that interrupts that knows the reason for the interruption, so generally speaking the interrupting thread needs to communicate the intention to the interrupted thread, unless it's implicitly clear from the context. For example, if someone pokes at me while I'm reading a book, and I look up at him, I expect him to tell me what he wants. If he gives me a blank stare, (and it's not clear from the context) then I will not know how to respond to the interruption.

by Andreas Lundblad | 
Reply

How would the interrupting thread communicate why it is interrupting another thread?

by Kevin Garrett | 
Reply

Threads can communicate with each other by for instance sharing a reference to a synchronized message queue, such as an ArrayBlockingQueue. The interrupting thread could then do msgQueue.offer("timeout") and the interrupted thread could do msgQueue.take() to retrieve the message.

by Andreas Lundblad | 
Reply

Add comment