On 07/15/2014 09:51 PM, John Rose wrote:
On Jul 11, 2014, at 10:56 AM, Remi Forax <fo...@univ-mlv.fr> wrote:
On 07/11/2014 06:18 PM, Vladimir Ivanov wrote:
http://cr.openjdk.java.net/~vlivanov/8050052/webrev.00
https://bugs.openjdk.java.net/browse/JDK-8050052
I've found myself writing the very same code as
MethodHandleStatics.uncaughException several times
and I wonder if it should not be an instance method of Throwable.
Something like:
public <E extends Throwable> E rethrow(Function<? super Throwable, ? extends E>
uncaughtHandler) {
if (this instanceof RuntimeException) {
throw (RuntimeException)this;
}
if (this instanceof Error) {
throw (Error)this;
}
return uncaughtHandler.apply(this);
}
in that case, throw uncaughtException(ex) can be replaced by throw
ex.rethrow(::newInternalError);
That's not a bad idea, but (odd for me to say this) it is too easy to use.
Occasionally there are reasons for *locally* subverting static checking of exceptions,
usually because we are writing a framework (like jli) that is polymorphic across
exception types. The checking is suppressed in one place so it can be reasserted
elsewhere, usually with some concerted wrapping and unwrapped (aka exception tunnelling).
An API which assists in doing this would be helpful, but it should be highly specific.
In effect it should say "I am temporarily suppressing all checked exceptions except
the locally checked ones X, Y, Z, and tunnelling the rest through a wrapper W."
try {
...
} catch (X | Y | Z e) {
throw e;
} catch (Throwable t) {
throw new W(t);
}
Could it be written more concise and with same flexibility using an API
trick?
Or do you have some language trick in mind which would take into account
the list of declared exception types on the method like:
void m() throws X, Y, Z, W {
try {
...
} catch (@NotDeclared Throwable t) { // meaning: Throwable & !(X |
Y | Z| W)
throw new W(t);
}
}
or even:
void m() throws X, Y, Z, @WrapRestWith W {
...
}
Regards, Peter
A secondary point is that the wrapper should generally not be something really general like
"Error"; perhaps "InternalError" or "AssertionError" would be more helpful.
But sometimes it needs to be a single *checked* exception. I guess I'm saying the API needs careful
definition. Time for a JEP (but not mine!).
It's an esthetic point, but "rethrow" is too breezy and quick to fully communicate valid
intentions (as sketched above), and too ready to ease subversion of checks. Imagine the stack
overflow articles saying, "hate Java exception checks? just type the following to get rid of
them all!" Don't. Want.
— John
