August 02, 2006
Multithreading, Java, & OSGiInterrupted Exceptions
Prior to this multithreading exercise, InterruptedException had always been a bit of a mystery to me. Was it really needed? Why? What should I do with it? Sample code frequently ignores it. Even Doug Lea didn't really seem to know what to do with it in Concurrent Programming in Java (Addison-Wesley, 2000).
ThreadManager gives a clear answer to these questions: InterruptedException must be obeyed—not ignored. The exception is thrown when a thread should exit posthaste. Ignoring it is almost certainly the wrong thing to do. Certainly ThreadManager won't work properly if you do. Proper operation of ThreadManager requires that threads exit when requested. If they don't, calls to stopAll() won't return.
The same applies to other exceptions, such as IOExceptions, which might indicate interruptions. These cases have always seemed more obvious to me; after all, there is often little one can do after receiving an exception on a socket. InterruptedException has always carried that temptation to try again.
Consistent with this advice, ThreadManager itself will break out of a call to stopAll() if it gets interrupted. Is this the right thing to do? It would seem to depend on the situation—something only the caller can know. When handling exceptions, deferring up the call stack generally seems like the right solution.
Previous Page |
1 Multithreading in Java & OSGi
|
2 Requirements
|
3 The Challenge
|
4 Problem Solving
|
5 ThreadManager Design Points
|
6 Multiple Blockers
|
7 Interrupt After Run
|
8 Interrupt Me Before I Run Again
|
9 Interrupted Exceptions
|
10 Conclusion
Next Page
|
 |
|
|||||||||||||||||||||||||||||
|
|
|
