On Wed, 13 Jan 2021 23:20:11 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:

>> You are correct. This is running in a performOnMainThreadWaiting:NO block.
>> So the JNI call likely already returned to Java before that block gets run 
>> on the AppKit thread.
>> But this seems to be the same as before and there was probably never any 
>> point to raising the JDK exception
>> I think in this case maybe what I should is update the macro to skip 
>> throwing the Java Exception if
>> it is being raised on the AppKit thread. No caller that I can see is 
>> expecting a RuntimeException for these failed actions so this seems to be 
>> very much an implementation decision. I am not even sure the code should be 
>> doing this. Rightly or wrongly GraphicsDevice.setFullScreenWindow(Window) 
>> declares no exceptions or possibility of failure.
>
> It is always better to wrap the java exception and always clear after each 
> callJavaMethod, so the next callJavaMethod will not be called when the java 
> exception was raised. At the same time in the place where we catch the 
> nsexception we can check does it have a java exception or not -> so we can 
> unwrap and raise again the java exception just before return to the java 
> code, or such exception in the NSApplication global catch block(including 
> currently missing NSApplication#reportException).

It is one way of doing it but it is much more heavyweight as it requires a 
carrier for the exception
and so goes against the approach here which is to be very lightweight in the 
sense of avoiding
creating classes - which so far as been the case.
And there is no need to wrap it. If its there, it will be just be passed on up 
to Java without any
work on our part.
And as for clearing, that's what I was doing before and that made sense if the 
intention is to carry on.
Since now we are always raising NSException there  that next Java call 
shouldn't happen as we always
should jump out.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2056

Reply via email to