[9] RFR (M): 8050052: Small cleanups in java.lang.invoke code

[Peter Levart]

On 07/15/2014 09:51 PM, John Rose wrote:
> On Jul 11, 2014, at 10:56 AM, Remi Forax <forax at 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