RFR: 8199149: Improve the exception message thrown by VarHandle of unsupported operation
Chen Liang
liach at openjdk.org
Wed Jul 19 00:55:42 UTC 2023
On Wed, 19 Jul 2023 00:12:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> `VarForm::getMemberName` currently throws UOE with no information if the requested access mode is unsupported. To provide the var handle information, move the access mode check to `VarHandle` so that the exception message can include the var handle information. Changes include:
>
> 1. change `VarHandle::checkAccessModeThenIsDirect` to check if the access mode is unsupported. This check is only needed for direct var handle.
> 2. change `VarHandle::getMethodHandleUncached` to call `getMemberNameOrNull` and throw UOE with an informative exception message if the access mode is unsupported
>
> The error message looks like:
>
> java.lang.UnsupportedOperationException: compareAndSet is not supported for VarHandle[varType=java.lang.String, coord=[class Foo$Goo]]
src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 93:
> 91: @ForceInline
> 92: boolean checkAccessModeThenIsDirect(VarHandle.AccessDescriptor ad) {
> 93: if (exact && accessModeType(ad.type) != ad.symbolicMethodTypeExact) {
Can we add a comment that the detailed UOE is thrown via `directTarget.getMethodHandleUncached`?
src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2020:
> 2018:
> 2019: static AccessMode valueFromOrdinal(int mode) {
> 2020: return modeToAccessMode.get(mode);
Can't this be simplified to `AccessMode.values()[mode]` since this is only rarely used in the exception logic?
If we do need a cache, I would recommend a stable array like
private static final @Stable AccessMode[] VALUES = values();
and users call this accessor instead.
The code in `getMethodHandleUncached` can benefit from this caching mechanism.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267424106
PR Review Comment: https://git.openjdk.org/jdk/pull/14928#discussion_r1267422748
More information about the core-libs-dev
mailing list