6

I have a code similar to this which is inside run() method of a Runnable and multiple instances of that Runnable get launched, 

do{
        try{
            String contractNum=contractNums.take();
           }catch(InterruptedException e){
            logger.error(e.getMessage(), e);
        }
  }while(!("*".equals(contractNum)));

Where contractNums is a BlockingQueue<String> shared by multiple threads. There are separate Runnables putting elements to this queue.

I am not sure about next steps after catching InterruptedException, should I terminate this thread by re throwing a RuntimeException ( so my while loop terminates ) or try to take next element from contractNum queue again and ignoring InterruptedException?

I am not sure if InterruptedException to be treated as a fatal condition for thread to terminate or keep it in while loop.

Please suggest.

Sabir Khan
  • 9,826
  • 7
  • 45
  • 98

2 Answers2

4

7.1.2 Interruption policies

Just as tasks should have a cancellation policy, threads should have an interruption policy. An interruption policy determines how a thread interprets an interruption request—what it does (if anything) when one is detected, what units of work are considered atomic with respect to interruption, and how quickly it reacts to interruption. The most sensible interruption policy is some form of thread-level or service- level cancellation: exit as quickly as practical, cleaning up if necessary, and pos- sibly notifying some owning entity that the thread is exiting. It is possible to establish other interruption policies, such as pausing or resuming a service, but threads or thread pools with nonstandard interruption policies may need to be restricted to tasks that have been written with an awareness of the policy.

7.1.3 Responding to interruption

As mentioned befor, when you call an interruptible blocking method such as Thread.sleep or BlockingQueue.put , there are two practical strategies for handling InterruptedException :

• Propagate the exception (possibly after some task-specific cleanup), making your method an interruptible blocking method, too; or

• Restore the interruption status so that code higher up on the call stack can deal with it.

Java Concurrency in Practice Chapter 7.

Specifically in your code you will need to make sure that if thread is interrupted your application logic is not broken. And it is indeed better to catch your interruption exception. What to with it is up to you just try to make sure that you don't break the application logic.

Adelin
  • 18,144
  • 26
  • 115
  • 175
  • 2
    Thanks for quoting that book. On page 143 - 144 , my scenario is described and suggests that I need to call , `Thread.currentThread.interrupt()` only once in an outer `finally` block when thread is about to finish - irrespective of number of times this exception is thrown. In inner catch, I should ignore exception and retry to `take()` elements from queue. – Sabir Khan Apr 07 '16 at 16:42
3

It depends. Are there places where you intentionally interrupt the thread, for example to tell it to finish up (for example during shutdown)? If not, you just need to handle possible spurious interrupts that will wake up the thread. If you don't want the processing to be affected, just ignore them. They're in absolutely no way fatal exceptions, and you don't need to log them (especially as errors).

Kayaman
  • 72,141
  • 5
  • 83
  • 121