Is it ever a safe to always ignore InterruptedException calling Thread sleep() in Java

Question

While working on a project I came across this code intended for a production system:

public static void sleepUntil(long millisecondToWake) {
    while (true) {
        long currentMillisecond = System.currentTimeMillis();
        if (currentMillisecond >= millisecondToWake) {
            break;
        }
        try {
            Thread.sleep(millisecondToWake - currentMillisecond);
        }
        catch (InterruptedException ignoredException) {
            // do nothing
        }
    }
}

I've always stuck to the basic principle of never dropping exceptions as exposed by Joshua Bloch in Effective Java as well as supported with my own extensive experience having to debug code where someone else did drop an exception. To date, I have not found a case where it is a good idea (sometimes catching checked exception and throwing an runtime is debatably reasonable but I am not talking about those cases here).

Thanks in advance for any comments.

never is a good option leaving a catch blank. first of all you will not notice a malfunction of your code. read when this exception is produced and write code expecting the exception. — logoff, Jul 24 '13 at 11:07

StuPointerException · Answer 1 · 2013-07-24T11:27:43.367

5

Here is a great article about this particular exception:

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

Basically though, it shouldn't be ignored, the very least the code should do is propagate the interruption:

catch (InterruptedException e) { 
    // Restore the interrupted status
    Thread.currentThread().interrupt();
}

The author doesn't care that the sleep of his Thread is interrupted (which is a valid reason to swallow the exception); however the interruption might be required elsewhere in a Thread that the author didn't know or think about when he write his code:

whether or not you plan to act on the interrupt request, you still want to reinterrupt the current thread because a single interruption request may have multiple "recipients." The standard thread pool (ThreadPoolExecutor) worker thread implementation is responsive to interruption, so interrupting a task running in a thread pool may have the effect of both canceling the task and notifying the execution thread that the thread pool is shutting down.

edited Jul 24 '13 at 11:27

answered Jul 24 '13 at 11:08

StuPointerException

7,117
5
29
54

Strange that your code sample does not propagate the exception. – JB Nizet Jul 24 '13 at 11:10
I think the idea is that the author wants the thread to sleep and not have to worry about dealing with exception at all. Not agreeing with it or defending it. Just soliciting more educated opinions about it. I did read the IBM article. It doesn't address the case of sleep in particular. If the worse thing that can happen is that JVM can't exist until the sleep is over, then I suspect the author of this code will be OK with it, but I am wondering if it cause worse problems. Thanks! – codeotaku Jul 24 '13 at 11:18
@JBNizet not strange at all. I didn't mention propagating the exception, I said propagate the interruption. – StuPointerException Jul 24 '13 at 11:20
I've updated my answer to include a little more detail. The danger of just ignoring the exception is mostly innocuous, unless I happen to call this code from a Thread that I implement which relies on interrupts for some important task; in which case I would start to see strange behaviour! – StuPointerException Jul 24 '13 at 11:32
Yes, I was thinking it was innocuous myself in this particular case, but the practice of dropping any exception just rubs me the in such a wrong way that I was hoping it was worse than that because I am trying to build up an case against this code so I can get it changed. However, as it stands, I don't think I'll win the argument. Oh well. – codeotaku Jul 24 '13 at 11:59
None of this seems to answer the OP's original question. What is wrong with just swallowing the exception in the case of Thread.sleep()? Assuming that the caller does not care about the interrupt(s). – Charles Roth Mar 18 '19 at 19:02

score 3 · Answer 2 · answered Jul 24 '13 at 11:09

3

It does not seem a reasonable approach in that specific example. In particular, if a user wants to exit the program (for example), the JVM will hang until your sleeping method ends, which seems unreasonable.

IMO, the only situation where you can safely ignore an InterruptedException is where:

you have full control of the thread executing your method, and
you immediately exit after the exception is ignored.

In any other situation, you should: reset the interrupted flag and exit promptly.

For example, this would be ok:

//the task is local, nobody else can access it
final Runnable localRunnable = new Runnable() {
    public void run() {
        //catch, ignore and exit immediately
        try { Thread.sleep(10000); } catch (InterruptedException e) {}
    }
}
//it is your own thread and you have full control over it
new Thread(localRunnable).start();

answered Jul 24 '13 at 11:09

assylias

321,522
82
660
783

Besides blocking an immediate JVM exit, are there other bad possible outcomes? What does InterruptedException really signal anyway? That's not clear to me either. Thanks. – codeotaku Jul 24 '13 at 11:21
@codeotaku interruption is the mechanism used in Java to ask a thread to stop what it's doing. For example if a thread is downloading a large file and you interrupt that thread, you should expect it to stop the download, clean up resources (close sockets etc.) and exit. When a task ignores interruptions, it makes it impossible to stop it. For example, there are many questions on SO about third party libraries that ignore interruptions and make them very unfriendly. The only workaround in such a situation is to run the code in its own process, which complicates things unnecessarily... – assylias Jul 24 '13 at 11:37

Is it ever a safe to always ignore InterruptedException calling Thread sleep() in Java

2 Answers2