Time to put a stop to Thread.stop?

[Vitaly Davidovich]

There's also Unsafe.throwException which can be used to rethrow checked
exceptions.  Without getting into another debate over checked exceptions,
this approach is much better than Thread.stop.

Sent from my phone
On May 15, 2013 4:06 AM, "David Holmes" <david.holmes at oracle.com> wrote:

> On 15/05/2013 3:16 PM, Martin Buchholz wrote:
>
>> On Tue, May 14, 2013 at 8:17 PM, David Holmes <david.holmes at oracle.com
>> <mailto:david.holmes at oracle.**com <david.holmes at oracle.com>>> wrote:
>>
>>     On 15/05/2013 2:57 AM, Martin Buchholz wrote:
>>
>>         On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters
>>         <jeroen at sumatra.nl <mailto:jeroen at sumatra.nl>> wrote:
>>
>>             IMO Thread.currentThread().stop(__**new Throwable()) should
>>             continue to work.
>>             It is not unsafe and it is probably used in a lot of code to
>>             workaround the
>>             madness that is checked exceptions.
>>
>>
>>     That is truly awful! Why wouldn't people just wrap in a runtime
>>     exception ???? Truly, truly awful. :(
>>
>>
>> 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.
>
>  I don't think there's a generally accepted
>> solution, although there's more than one (sneaky) way to do it, and we
>> could stop using Thread.stop for that purpose.
>>
>
>
>      If we had to we could special-case for currentThread. :(
>>
>>
>>         There are existing JDK tests that use currentThread().stop to
>>         implement the
>>         occasionally necessary sneakyThrow.
>>
>>         I suspect there are important uses of unsafe otherThread.stop in
>>         the real
>>         world, where it is used as a last resort to shut down an
>>         "application"
>>         running within a java vm, and works reasonably well in practice.
>>
>>
>>     I would dispute that it can work "reasonably well in practice" given
>>     the near impossibility of writing async-exception-safe non-trivial
>>     Java code. That aside, the proposal is only for the stop(throwable)
>>     form which I would not expect to be used for the termination case.
>>
>>
>> I agree it's unsafe.  But you have the same problem to a lesser extent
>> with kill -9, which is also an indispensable part of every engineer's
>> toolbox, and works well enough in practice.
>>
>
> There is a huge difference between blowing away a complete process with
> kill and having a single thread starting to propagate an async exception,
> unwinding its stack and executing finally blocks with completely broken
> state invariants.
>
> David
>