8267989: Exceptions thrown during upcalls should be handled #543
This patch regularizes exception handling for exceptions thrown during upcalls. Exceptions thrown during upcalls are now always handled by printing out the stack trace and then calling
I've added some documentation for the exception handling to
The text was updated successfully, but these errors were encountered:
@JornVernee This change now passes all automated pre-integration checks.
After integration, the commit message for the final commit will be:
At the time when this comment was updated there had been no new commits pushed to the
I've switched to using
I've removed the public
Finally, I've changed the test to always print the output as well, besides checking the contents.
I still have to add an eager check (and test) to see if the target of an upcall throws an exception.
Adapt the existing exception check done by MemoryHandles to be more lenient towards bound method handles which might or might not throw an exception, and re-use that check.
I've now added the eager exception checking to upcallStub.
As discussed offline, this reuses the exception check done for the VarHandle adapters, but makes the check more lenient towards BoundMetrhodHandles that might or might not throw an exception. The current check was too conservative toward rejecting such handles, because it rejects a BoundMehtodHandle that contained any MethodHandle field that could throw an exception. But, such an exception might be caught be an exclosing method handle. (see also https://bugs.openjdk.java.net/browse/JDK-8268031)
Instead, when a filter used for a var handle combinator throws a checked a exception when invoked, it is caught, and an IllegalStateException is thrown instead (with the original exception as the cause).