On 07/18/2014 03:54 AM, John Rose wrote:
FTR, I captured this issue:
https://bugs.openjdk.java.net/browse/JDK-8051294
(Wish they were all so easy to catch.)
— John
Hi John,
I like the way the proposed API is composable but i fear that people
will still forget to first call throwIfUnchecked() most of the time.
I think we should not implement a throwSuppressedIf because a suppressed
exception is not a primary one thus it's a more an information when
debugging than an exception a code should act upon.
I'm not sure that looking recursively for a cause ( :) ) is a good idea,
changing the behavior of a program because an exception buried under 10
others doesn't seem appealing to me.
Also there is a bug hidden in your implementation of throwCauseIf, you
return the value of cause.throwCauseIf instead of this.
cheers,
Rémi
On Jul 17, 2014, at 5:12 PM, John Rose <john.r.r...@oracle.com> wrote:
On Jul 16, 2014, at 11:20 AM, Peter Levart <peter.lev...@gmail.com> wrote:
An alternative could be:
public Throwable throwIfUnchecked() {
if (this instanceof RuntimeException) throw (RuntimeException) this;
if (this instanceof Error) throw (Error) this;
return this;
}
Then use it like:
try {
...
} catch (Throwable t) {
throw new WrapperException(t.throwIfUnchecked());
}
I like this one. (I wish we could declare This types, so that
TYPEOF[t.throwIfUnchecked()] == TYPEOF[t].)
It puts the throw of the "less dangerous" exception type inside the subroutine, making
the wrapping and the "more dangerous" (more ad hoc) exception be explicit and in-line.
To complete the picture, add:
public <X extends Throwable> Throwable throwIf(Class<X> exClass) throws X {
if (exClass.isInstance(this)) throw exClass.cast(this);
return this;
}
...to be used as:
try {
...
} catch (Throwable t) {
t.throwIfUnchecked().throwIf(X.class).throwIf(Y.class).throwIf(Z.class);
throw new WrapperException(t);
}
Or some other combination of sequential and/or fluent calls.
— John