Time to put a stop to Thread.stop? (original) (raw)

Martin Buchholz martinrb at google.com
Wed May 15 05:16:06 UTC 2013

On Tue, May 14, 2013 at 8:17 PM, David Holmes <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> 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? 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.

More information about the core-libs-dev mailing list