On 15/05/2013 3:16 PM, Martin Buchholz wrote:
On Tue, May 14, 2013 at 8:17 PM, David Holmes <david.hol...@oracle.com
<mailto:david.hol...@oracle.com>> wrote:
On 15/05/2013 2:57 AM, Martin Buchholz wrote:
On Tue, May 14, 2013 at 7:45 AM, Jeroen Frijters
<jer...@sumatra.nl <mailto:jer...@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
