Time to put a stop to Thread.stop?
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>
>> IMO Thread.currentThread().stop(**new Throwable()) should continue to
>>> It is not unsafe and it is probably used in a lot of code to workaround
>>> 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
>> 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