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

[Remi Forax]

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.

Maybe, but compared to the code people write now when they have to 
manage a Throwable or an Exception,
i think it's still a win (checked exceptions and unchecked exceptions 
flows are rarely separated :( ).

I agree that the name should be changed because it convey a wrong 
message (see below).

Anyway, if IDEs still propose "throws" instead of "try/catch" as their 
first quickfix, the Java world will not sink.

> 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.

Not only when writing framework, you need this method in user code too 
when you use an API that wrap all exceptions in an exception (usually 
checked)
    try {
      return methodHandle.invokeExact(...);
    } catch(Throwable t) {
      // what I'm expected to write here
    }
or
   try {
     return future.get();
   } catch(ExecutionException e) {
     // what I'm expected to write here
   }
and you can also use it to tunnel a checked exception into another 
checked exception.

>    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."

The API doesn't have to manage checked exception X, Y, Z because most of 
the time you will use this method in a catch block,
so you can have more catch blocks on top of the catch block that use the 
method.

>
> 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!).

yes, the wrapper exception is different for each use case, that why the 
method takes a java.util.function.Function as parameter,
to ask the user to specify the wrapper exception.

>
> 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.

I agree, "tunnel" is maybe better, at least it's meaning is darker :)
anyway, I'm not good at name, I'm sure someone can come with a better name.

> Imagine the stack overflow articles saying, "hate Java exception checks?  just type the following to get rid of them all!"  Don't.  Want.

SO question/answers are usually more balanced from my opinion (if people 
don't stop reading after the first answer).
And as I said, it will be better than letting people to write their own 
code.

BTW, it occurs to me that instead of using several instanceof, the 
method "tunnel" can have several overrides, ones for Throwable, 
RuntimeException and Error.

>
> — John

Rémi