Time to put a stop to Thread.stop?

[David Holmes]

On 25/05/2013 4:14 AM, Martin Buchholz wrote:
> On Fri, May 24, 2013 at 6:18 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:
>
>>
>> The webrev with the proposed changes is here. As I mentioned in one of the
>> replies, there are 4 j.u.c tests that need to be updated so I've changed
>> these tests to use Unsafe.throwException.
>>
>
> Alan, you're telling everyone there's no need for Thread.stop, but you are
> replacing usages in tests with calls to Unsafe, which is not available to
> normal code.  So you have a kind of moral obligation here to replace usages
> with "ordinary" java code.  There are other ways to do sneakyThrow, and
> perhaps a sneakyRethrow method should be added to the jdk test library.

I disagree. The tests are using stop(x) as a means of fault injection, 
to simulate something that is "impossible" in correctly written Java 
code. Now because there are nasty ways to do the "impossible" the test 
simulated them to see if the code under test was robust. I think that is 
going above and beyond what the test needed to do. So I find it 
non-sensical to say that we have to have a Java way of throwing checked 
exceptions in a way that is impossible in the Java programming language.

> Ordinary java code should be able to simply catch and rethrow a Throwable
> if type analysis can "prove" that the exception is not an Exception.
>
> As a data point, Doug uses this:
>
> (Doug, it's not obvious to me why you handle Error and RuntimeException
> specially)
>
>      /**
>       * A version of "sneaky throw" to relay exceptions
>       */
>      static void rethrow(final Throwable ex) {
>          if (ex != null) {
>              if (ex instanceof Error)
>                  throw (Error)ex;
>              if (ex instanceof RuntimeException)
>                  throw (RuntimeException)ex;
>              ForkJoinTask.<RuntimeException>uncheckedThrow(ex);
>          }
>      }

This is a variation of the rethrow() method "we" have been using since 
1996 at least - and the more precise exception typing we have in Java 7 
should remove the need to handle Error and RuntimeException this way - 
we should be able to catch as part of multi-catch and re-throw directly.

>      /**
>       * The sneaky part of sneaky throw, relying on generics
>       * limitations to evade compiler complaints about rethrowing
>       * unchecked exceptions
>       */
>      @SuppressWarnings("unchecked") static <T extends Throwable>
>          void uncheckedThrow(Throwable t) throws T {
>          if (t != null)
>              throw (T)t; // rely on vacuous cast
>      }

That truly is sneaky. I hadn't realized we had stooped this low ;-) Not 
100% sure why this works though. I'd call that a javac bug.

David
-----