Alan Bateman wrote:
On 25/05/2013 12:35, Alan Bateman wrote:
On 24/05/2013 19:14, Martin Buchholz wrote:
:
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.
For these the tests then it shouldn't really matter but if you or
Doug would prefer if they are changed to use sneakyThrow then we can
do that.
Martin has pushed updates to the 4 tests to the jsr166 CVS so I'll
going to push these to jdk8/tl forest along with the Thread.stop changes.
I noticed the other day when using Java 8 that Thread.stop(Throwable)
was throwing an UOE. Unfortunately I missed the discussion in May
amongst the thousands of other important JDK emails. Thus I presume
that nothing I might have to say on the matter would change what is
currently in the OpenJDK ;-) But I'd like to state it "for the record"
anyway.
Throwing checked exceptions in an unchecked context is, IMHO, something
one should almost never do, except maybe in test cases. Up to now, I've
known of quite a few ways to do this though:
1. Thread.stop(Throwable) with some mangling - see ThrowerConcurrent in
http://www.javaspecialists.eu/archive/Issue144.html
2. Abusing generics
3. Class.newInstance(), described in Java Puzzlers
(http://www.javaspecialists.eu/archive/Issue144.html)
4. Unsafe.throwException() similar to ThrowerConcurrent in #1.
Since this is something that we should not do anyway, it is no harm to
remove one of the ways, this being Thread.stop(Throwable).
However, there is another use case. If you cause a deadlock with
ReentrantLock, you might be able to bust out of that by sending a
DeadlockVictimError to one of the threads in the deadlock. This would
not work for threads deadlocked with synchronized. I agree this is a
rare situation and we should rather avoid the deadlock. But it is
useful to be able to do it.
Here are two newsletters where I write about this:
http://www.javaspecialists.eu/archive/Issue130.html
http://www.javaspecialists.eu/archive/Issue160.html
Now it is enough of an edge case that I can accept using
Unsafe.throwException() as being the "proper" solution. Since it is
"unsafe", we might as well use that mechanism. However, it is yet
another temptation to use Unsafe, which, of course, we should avoid,
seeing that it is, ahem, "unsafe" ;-)
Regards
Heinz
