Time to put a stop to Thread.stop?

[David Holmes]

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>> 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