At present, MethodHandle's invokeExact() is declared as the following:
>From [1]:
> @IntrinsicCandidate
> public final native @PolymorphicSignature Object invokeExact(Object...
> args) throws Throwable;
I think this is a case where this method should probably never have
thrown a checked exception and I'd like to make the case and
test the waters and see if others have the appetite to see this change. I'm
assuming that altering this function signature is a no-go and a new
invokeExactUnchecked() is preferable.
Making the Case
I know, I know there's no PL bikeshed greater than that checked vs
unchecked exceptions -- looking at you, Future.get() -- but I think this
case is fundamentally different. MethodHandles are kindof a low-level niche
unit of JVM magic. That's why it's already an *exceptional* function given
its @PolymorphicSignature. Pun intended.
Most APIs for general use *should* drive good, sane programming habits, but
if you're reaching for MethodHandles you're probably doing something you
want a good deal of control over. There are a ton of ways it's already
expected to be a "just trust me" escape hatch already. MethodHandles are
often used with the expectation that they have to be static finals for them
to be inlined as if they are regular code. It is very awkward
and counter-productive even to have to introduce a *try { } catch(Throwable
e) { } *with all of its syntactic, bytecode, *and* JIT/inlining baggage.
Just throwing the invokeExact() call in a function or a lambda to mask out
the try-catch just pours back the layers you're futzing around with
MethoHandles to peel back.
If there's an interest and an appetite for it I'd love to take a crack at
implementing it. Any pointers are welcome!
[0]: https://bugs.openjdk.java.net/browse/JDK-8254354
[1]:
https://github.com/openjdk/jdk/blame/master/src/java.base/share/classes/java/lang/invoke/MethodHandle.java
