On Fri, 9 Feb 2024 03:12:57 GMT, Phil Race <p...@openjdk.org> wrote:
>> Yes. However, it's "only" in the assertion callback that only exists in
>> debug VMs. And an original exception isn't lost.
>
> Perhaps what we should do here is
> if (ExceptionCheck) {
> ExceptionDescribe
> ExceptionClear
> }
> So someone can "see" [yes, this means it isn't propagated but we've printed
> it and we have the assert coming up anyway] the text of the original
> exception, and the debugging code is safe to make the calls it wants.
>
> The alternatives are that the debugging code in the case of
> ExceptionCheck==TRUE just do what it takes to silence the JNI warnings ,
> assuming that TRUE is never not a possibility, so no real problem, but I
> don't know see how we can be sure about that for ALL callers of this assert
> code. (BTW I wonder if the reason the current code didn't do as expected is
> because ExceptionCheck isn't doing what we expect, but I don't see how), or
> alternative number 2 is that the debug code simply bails in the face of a
> pending exception, ie
> if (ExceptionCheck) {
> return;
> }
As far as I can see, the real problem is that `DWMIsCompositionEnabled` calls a
Java method and does not check if an exception occurred. It should do it
according to the JNI specification.
I can assume `initScreens(env)` does not call JNI methods, therefore no JNI
warning is produced in the regular code flow where no assertions fail.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17404#discussion_r1484385819
