• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

IllegalInterrupt my eye!

 
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
consider this code... taken mostly from the book, except for my twist on Samuel Beckett and better field variable handling:



What's the result??

Well on my jvm you get:
What are we doing? We waiting for the calculator...
What are we doing? We waiting for the calculator...
What are we doing? We waiting for the calculator...
calculator is calculating...


So why isn't the executed?

because the damn exception is never thrown!

They never tell you this in the book also. They say that the IllegalMonitorException is unchecked.. So, what about the InterruptException?? How is that thrown? Not with notify() or notifyAll()? It's not even in the javadocs.I have XP and JVM 1.6.0_21. They never said that a notify() or notifyAll() would throw that exception either. So what is an Interrupt Exception anyway? Is it something that can only be thrown manually? Why is it unchecked? What throws it?


 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What do you mean, not in the javadocs? When I looked up InterruptedException in my javadocs (which are surely the same as yours) it said this:

Thrown when a thread is waiting, sleeping, or otherwise paused for a long time and another thread interrupts it using the interrupt method in class Thread.



So that answers all your questions, doesn't it? And knowing that, you should be able to determine why the text you never saw was never displayed.
 
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Which "the book" are you using, anyway? There are many.

I can't tell why you might think that InterruptedException should be thrown. But I would suggest that (a) as Paul said, you should look at the javadoc, and (b) you should pay attention to details. InterruptException != InterruptedException, and both are !!!= IllegalInterrupt. Two out of three of the preceding names are completely made up, and not by me. Your compiler will like you much better if you use the actual names of things. And we will have a better chance of understanding what you're talking about.
 
See Furst
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
and you two were paying too much attention to mis-spellings and my comments about javadocs to think about the question.. Why doesn't the code run? Why is the execption not thrown?

The answer, I believe, is, as I have read in the javadocs is that interrupt() is not called on the thread, which seems to be the only thing that will cause a sleeping or waiting thread to throw an InterruptedException()

The book I am referring to is the SCJP study guide by Sierra and Bates. The chapter on threads doesn't really explain how interrupts are thrown except that they are thrown by sleep and wait. Something has to set the state of the thread to interrupted.. and I believe that is the interrupt() call.

interrupt

public void interrupt()

Interrupts this thread.

Unless the current thread is interrupting itself, which is always permitted, the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown.

If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.



So in the code above... My next question is... a thread has to interrupt itself to get that code executed? OR another thread has to interrupt the one that is waiting? My assumption is that the code is just bad design, which most code for this test seems to be ( maybe it's just this book?)

Cheers
 
Mike Simmons
Master Rancher
Posts: 4806
72
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

See Furst wrote:and you two were paying too much attention to mis-spellings and my comments about javadocs to think about the question.


Hardly. Paul pointed you directly at the answer.

See Furst wrote:The answer, I believe, is, as I have read in the javadocs is that interrupt() is not called on the thread, which seems to be the only thing that will cause a sleeping or waiting thread to throw an InterruptedException()


Correct. Glad you were able to see it by looking again.

See Furst wrote:My next question is... a thread has to interrupt itself to get that code executed? OR another thread has to interrupt the one that is waiting? My assumption is that the code is just bad design, which most code for this test seems to be (maybe it's just this book?)


It looks like you, or someone, has miscopied the code. Looking at the SCJP 6 book, p. 753, I see:

The most important difference here is that in the "Total is:" line is outside the catch block. The author knew that InterruptedException should never be thrown, since there is no interrupt(). The catch block is only there to make the compiler happy; it should never get executed. Instead the "Total is:" line should be executed shortly after c.wait() finishes, which should be shortly after the call to notifyAll() from the other thread.

Also, sometimes code will intentionally contain bad code in order to discuss a point or teach you something. Bad designs occur in real life, after all, and part of programming is learning to figure out what the problem is, and how to fix it. In this case, there's a problem in the code because the call to wait() is not contained in a loop - this is discussed in the very next section of the book.
 
See Furst
Greenhorn
Posts: 29
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Mike Simmons wrote:

See Furst wrote:and you two were paying too much attention to mis-spellings and my comments about javadocs to think about the question.


Hardly. Paul pointed you directly at the answer.

See Furst wrote:The answer, I believe, is, as I have read in the javadocs is that interrupt() is not called on the thread, which seems to be the only thing that will cause a sleeping or waiting thread to throw an InterruptedException()


Correct. Glad you were able to see it by looking again.

See Furst wrote:My next question is... a thread has to interrupt itself to get that code executed? OR another thread has to interrupt the one that is waiting? My assumption is that the code is just bad design, which most code for this test seems to be (maybe it's just this book?)


It looks like you, or someone, has miscopied the code. Looking at the SCJP 6 book, p. 753, I see:

The most important difference here is that in the "Total is:" line is outside the catch block. The author knew that InterruptedException should never be thrown, since there is no interrupt(). The catch block is only there to make the compiler happy; it should never get executed. Instead the "Total is:" line should be executed shortly after c.wait() finishes, which should be shortly after the call to notifyAll() from the other thread.

Also, sometimes code will intentionally contain bad code in order to discuss a point or teach you something. Bad designs occur in real life, after all, and part of programming is learning to figure out what the problem is, and how to fix it. In this case, there's a problem in the code because the call to wait() is not contained in a loop - this is discussed in the very next section of the book.



By Jove! Thanks Mike for that clarification.. I think I'll start by learning to read... LOL
 
reply
    Bookmark Topic Watch Topic
  • New Topic