[concurrency-interest] Thread interruption protocol: InterruptedException is a "checked" exception, correct?

Gregg Wonderly gregg at cytetech.com
Wed May 20 14:54:25 EDT 2009

Any thread may be interrupted at any point in its execution path.  The fact that 
InterruptedException is a checked exception is the predominant issue from my 
perspective.  It can be thrown from code which does not declare it to be thrown 
as a checked exception.  InterruptedException should be a RuntimeException 
because of this...  But, this will likely never be something that can be changed 
for backward compatibility.

One "solution" could be to create a new RuntimeException, perhaps 
ThreadInterruptedException and the documentation changed to deprecate 
InterruptedException in favor of such a RuntimException.  But changing what is 
thrown would be a compatibility issue in and of itself.  Thus, a new 
Class.forName() derivative would have to be created as well which would throw 
this new exception.

Thus, I'm not convinced there is anything you can do besides what you are doing, 
and catch "Exception" and do "instanceof" checks to see if it is something that 
you know how to handle specifically.

Gregg Wonderly

Péter Kovács wrote:
> Thank you, Marcelo!
> May this be, then, a bug in the JVM?
> Thanks
> Peter
> 2009/5/20 Marcelo Fukushima <takeshi10 at gmail.com>:
>> in your code, the exception seems to come from native code, which also
>> doesnt have the checked exception restrictions that javac enforces (i
>> think)
>> 2009/5/20 Péter Kovács <peter.kovacs.1.0rc at gmail.com>:
>>> Tom,
>>> I highly appreciate your input.
>>> The doc you quoted says that the original exception is wrapped in an
>>> InvocationTargetException instance. Similarly, I'd expect that if an
>>> exception occurs during Class loading, it is wrapped in an
>>> ExceptionInInitializerError, correct?
>>> What we're seeing in our case is a plain InterruptedException:
>>> ...
>>> Caused by: java.lang.InterruptedException
>>> at java.lang.Class.forName0(Native Method)
>>> at java.lang.Class.forName(Class.java:164)
>>> ...
>>> Thanks
>>> Peter
>>> 2009/5/20 Tom Hawtin <Thomas.Hawtin at sun.com>:
>>>> Péter Kovács wrote:
>>>>> Is it possible to get java.lang.InterruptedException, even if none of
>>>>> the method along the call stack declares this exception?
>>>>> We are experiencing such a case. Class.forName(String) appears to
>>>>> throw the exception.
>>>> Class.newInstance is more likely to be the culprit:
>>>> "Note that this method propagates any exception thrown by the nullary
>>>> constructor, including a checked exception. Use of this method effectively
>>>> bypasses the compile-time exception checking that would otherwise be
>>>> performed by the compiler. The Constructor.newInstance method avoids this
>>>> problem by wrapping any exception thrown by the constructor in a (checked)
>>>> InvocationTargetException."
>>>> http://java.sun.com/javase/6/docs/api/java/lang/Class.html#newInstance()
>>>> The same thing can be done with Thread.stop(Throwable), unchecked casts and
>>>> playing silly buggers with bytecode
>>>>> Is it not a breach of one of the fundamental contracts of the Java
>>>>> language: "checked" exception are not allowed to be thrown in a method
>>>>> without this method being declared to (potentially) throw it? (We
>>>>> catch this exception as a Throwable in a catch(Throwable) clause.)
>>>> Of the language yes (with exception for unsafe casts); of the VM no.
>>>> Tom Hawtin
>>> _______________________________________________
>>> Concurrency-interest mailing list
>>> Concurrency-interest at cs.oswego.edu
>>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>> --
>> []'s
>> Marcelo Takeshi Fukushima
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list