Details
-
Bug
-
Resolution: Fixed
-
P3
-
None
-
repo-panama
Description
The current VarHandle combinators, such as filterCoordinate, which are currently exposed through jdk.incubator.foreign.MemoryHandles check whether the filter MethodHandle used for the combinator throws any checked exceptions.
In the case where the filter handle is a BoundMethodHandle, the check walks all the fields of the BoundMehtodHandle, and if they are MethodHandles themselves, recursively checks if they throw any exception.
However, this check is too strict, as even though a MethodHandle bound to a BoundMethodHandle might throw an exception, it could be caught higher up in the method handle chain, making it so the top level method handle will never throw an exception.
The attached example illustrates the problem. Even though the exception thrown by the method 'm' is handled by the catchException combinator, the call to filterCoordinates still throws an IllegalArgumentException.
In the case where the filter handle is a BoundMethodHandle, the check walks all the fields of the BoundMehtodHandle, and if they are MethodHandles themselves, recursively checks if they throw any exception.
However, this check is too strict, as even though a MethodHandle bound to a BoundMethodHandle might throw an exception, it could be caught higher up in the method handle chain, making it so the top level method handle will never throw an exception.
The attached example illustrates the problem. Even though the exception thrown by the method 'm' is handled by the catchException combinator, the call to filterCoordinates still throws an IllegalArgumentException.