Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread questions  RSS feed

 
Bob Young
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am reviewing Paul Hyde's Java Thread Programming book and I need some clarifications. In an alternative example to the use of the deprecated stop() method he uses this code snippet:
public void run() {
//note run() does not throw InterruptedException
// missing code
catch (InterruptedException x) {
Thread.currentThread().interrupt(): // reassert
}
In the discussion of the example he states: "If there were more interruptible statements like sleep() or wait(), they would not throw an InterruptedException unless the interrupt had been reasserted. You don't want them to throw an InterruptedException right away because the thread has been signaled to clean up and die."
I do not understand either of these two statements. If there were other sleep() or wait() statements, why couldn't they throw an InterruptedException unless reasserted? I am totally at a loss as to the meaning of the second sentence?
In looking at a Sun article: "Why Are Thread.stop, Thread.suspend, Thread.resume and Runtime.runFinalizersOnExit Deprecated?", I find the following that applies: "For this technique to work, it's critical that any method that catches an interrupt exception and is not prepared to deal with it immediately reasserts the exception. We say reasserts rather than rethrows, because it is not always possible to rethrow the exception. If the method that catches the InterruptedException is not declared to throw this (checked) exception, then it should "reinterrupt itself" with the following incantation:
Thread.currentThread().interrupt();
This ensures that the Thread will reraise the InterruptedException as soon as it is able. "
Why is it not always possible to rethrow the exception?
I noticed that in Paul's example, the run() method was not prepared to handle the InterruptedException and reinterrupted itself as per the Sun document. When interrupting itself in this fashion, the exception is passed up to the calling method, which would be start() and then main where start was invocked. Is this correct logic? Thanks in advance.
 
Cindy Glass
"The Hood"
Sheriff
Posts: 8521
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Lets move this over to threads and see if you get some response over there.
 
Peter Haggar
author
Ranch Hand
Posts: 106
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Bob Young:
Why is it not always possible to rethrow the exception?

InterruptedException is a checked exception. Therefore, if it propogates from a method, it must be on the method's throws clause, otherwise the code will not compile. If your method does not list it on its throws clause, you cannot rethrow it, you must reassert it by calling interrupt().

I noticed that in Paul's example, the run() method was not prepared to handle the InterruptedException and reinterrupted itself as per the Sun document. When interrupting itself in this fashion, the exception is passed up to the calling method, which would be start() and then main where start was invocked. Is this correct logic? Thanks in advance.

The calling method of run() is not start(). start() causes the run() method to be called, but when an exception occurs in run() it will not go back to start(). When an exception occurs in run() you must catch it there, or the thread will terminate. Before the thread terminates, the method uncaughtException() is invoked which is part of the ThreadGroup class. (Every thread is a member of a ThreadGroup.)
Peter Haggar
------------------
Senior Software Engineer, IBM
author of: Practical Java
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!