Community
Participate
Working Groups
I just blogged about the rule Don't swallow InterruptedException. Call Thread.currentThread().interrupt() instead. (http://michaelscharf.blogspot.com/2006/09/dont-swallow-interruptedexception-call.html) It is based on a paper by Brian Goetz called "Dealing with InterruptedException" http://www-128.ibm.com/developerworks/java/library/j-jtp05236.html and the book "Java Concurrency in Practice" By BriaBrian Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, and Doug Lea (http://www.amazon.com/exec/obidos/ASIN/0321349601/ref=nosim/none0b69). However browsing the eclipse code (after publishing the blog entry :-/), I have the impression that InterruptedException are used differently and the above rule does not apply because I have seen only a few place where isInterrupted and interrupted is called.... Another indication is that org.eclipse.ui.examples.jobs the jobs do exactly the opposite of that recommendation: they call try { Thread.sleep(sleep); } catch (InterruptedException e) { Thread.interrupted(); } Thread.interrupted is not needed anyway because an InterruptedException resets the interrupted state anyway. But that gives me an indication that the paradigms of the jobs framework and java (1.5) are fundamentally different. I hope I am wrong and this bug will be marked invalid!
Setting the bug description back to what it looked like before I added myself to the cc list.
This looks like a bug in the example to me. I believe the rule you quoted does apply. BTW, if you frequently call operations that may throw InterruptedException, you don't need to check for isInterrupted(), assuming that you handle the exceptions appropriately by re-throwing or calling interrupt().
I agree this just looks like a bug in the example code. However, it's worth noting that the Java interrupt mechanism is not generally used by Eclipse for handling cancelation (partly because it's so poorly specified that this is what it is intended for, and anyone could throw it for some other reason). Instead, Eclipse almost universally uses IProgressMonitor in long running or blocking operations where cancelation support is needed. Eclipse does however use InterruptedException for a very special purpose within the UI thread. If the UI thread is blocked, and a thread that owns some lock calls Display.syncExec, deadlock would be likely to occur. The Eclipse workbench implementation of syncExec will interrupt the UI thread in this situation to break the deadlock. Often the "correct" pattern in Eclipse when InterruptedException is encountered in the UI thread is like this: while (true) { try { doSomeLongRunningOrBlockingWork(); break; catch (InterruptedException e) { //someone may be trying to do a syncExec, so spin the event loop and retry } while (display.readAndDispatch()) { //spin the event loop until no more events } } This is fairly complicated, but if you're doing long running or blocking operations in the UI thread you're asking for trouble anyway. This pattern is just used in the rare situations where it is not possible to fork the long running work into a non-UI thread.
Example code fixed.
> However, it's worth noting that the Java interrupt mechanism is not generally > used by Eclipse for handling cancelation (partly because it's so poorly > specified that this is what it is intended for, and anyone could throw it for > some other reason). Instead, Eclipse almost universally uses IProgressMonitor > in long running or blocking operations where cancelation support is needed. Unfortunately, Thread.interrupt() is the *only* way to terminate a blocking call (see bug 157604). A long running call that is in a blocking call cannot be canceled by IProgressMonitor, because Thread.interrupt() is not called.
oops, I mean see bug 162577
