Time to put a stop to Thread.stop?
Martin Buchholz
martinrb at google.com
Wed May 29 02:35:06 UTC 2013
On Tue, May 28, 2013 at 6:43 PM, David Holmes <david.holmes at oracle.com>wrote:
> On 29/05/2013 11:23 AM, Martin Buchholz wrote:
>
>> [+compiler-dev]
>>
>>
>> On Wed, May 15, 2013 at 1:05 AM, David Holmes <david.holmes at oracle.com>**
>> wrote:
>>
>> On 15/05/2013 3:16 PM, Martin Buchholz wrote:
>>>
>>>
>>>>
>>>> General purpose library code sometimes would like to rethrow an
>>>> exception that was previously caught.
>>>> How should it do that?
>>>>
>>>>
>>> Umm catch it and throw it. If it is a checked-exception that you want to
>>> propogate then you should have declared it on your method, else you are
>>> going to wrap it in a runtime exception or error. There is no need for
>>> such
>>> sleaze.
>>>
>>>
>>> Taking a closer look at one use of Thread.stop, I see that we use it to
>> throw a Throwable out of Callable.call. Which I think we should be able
>> to
>> do. But I can't.
>>
>
> Why do you think you should be able to throw an arbitrary Throwable from
> Callable.call?
>
>
Oops. It turns out I didn't know the definition of "checked exception".
"""
The checked exception classes are all exception classes other than the
unchecked exception classes. That is, the checked exception classes are all
subclasses of Throwable other than RuntimeException and its subclasses and
Error and its subclasses.
"""
So it's part of the contract of Callable that it must not throw a new
Throwable(). Which surprises me.
More information about the core-libs-dev
mailing list