Take a look at this example which let's assume runs in a thread/thread-pool context.
public void run() {
// Honor interrupts so that you can stop/kill the task
while (!Thread.currentThread().interrupted()) {
this.doSomeChunkOfWork();
}
}
The above code is a good example of how you would write a task which can be interrupted and processes data in chunks (think of reading from some source and processing data in parts). Now let's assume doSomeChunkOfWork
is interrupted and you catch an exception. Unless you set the flag again or maintain the interrupt status of the flag, the run
method won't be able to know that the processing deep down the call stack was interrupted when the method call returns which messes up our good logic.
This is the reason why you always set the status back so that methods down the call stack are aware of whether the thread was really interrupted or not. An analogy I would like to think for this is "don't sweep dirt under the rug". :)