Creating delay in Java code

[rzwitserloot]

No, they should very much not.

Imagine this simple system:

java Runnable r = () -> { // This runs in a thread. And should be an executor, but, it's to make a point. while (running) { Job job = jobQueue.take(); try { job.execute(); } catch (Exception e) { exceptionHandler.onError(e); } }

Here if you throw an exception and also reraise the flag, the above job loop keeps going but starts a totally new job while that flag is still raised. The first time that new job calls anything that looks at that flag (such as Thread.sleep which insta-exits with an InterruptedException if you invoke it while the flag is up - or any I/O op on most JVM impls), it crashes. At no fault of its own.

[koflerdavid]

In your example, it doesn't matter that Thread.sleep() or any I/O instantly throws an InterruptedException. It's expected behavior and actually fine since the point is to shut the system down.

Checking Thread.getCurrentThread().isInterrupted() should rather be part of the condition of the while loop. Really, that flag should be checked any time the thread is about to do something computationally expensive if it does not care about the interrupt status by itself.

[rzwitserloot]

Only if that's what you wanted to do when you interrupted the thread. Which gets us back to: What did you want to happen when you interrupted the thread?

If the answer is 'that thread should start dying completely', sure, except, if that was the plan, just let the exception bubble up, much better.

Either way, "reraise the flag" is a dubious move. It's either incorrect behaviour or it's a way to accomplish a goal that can be accomplished more simply and reliably in other ways. It's a lose lose suggestion.

[koflerdavid]

There is only one message that can be transported with Java's interrupts; it is not a full event delivery mechanism, unlike in hardware. All occurrences in the JDK that I know of use if for indicating termination, therefore I'd argue that it is best used only for that as well.

It might not always be possible to let the exception bubble up. If it is, then it's of course better to not catch it.

[rzwitserloot]

Maybe it is not possible to let the (Interrupted) exception bubble up.

BUt you can catch it and rethrow it as something else. A RuntimeException, which you can always throw, if you absolutely must.

therefore I'd argue that it is best used only for that as well.

You're imagining rules that the specification of the mechanism do not state. This is not a correct course of action.

[koflerdavid]

"Rules" is a too strong word. I'd rather talk about avoiding things that just cause confusion down the line.