On Wed, 13 Jan 2021 21:16:42 GMT, Phil Race <p...@openjdk.org> wrote:
>>> Since the next line throws NSException everything before this change and >>> after this change should cause control to reach the COCOA_EXIT macro. >> >> It does not, the JNI_COCOA_EXIT macro is executed on a different thread than >> JNI_COCOA_THROW_RUNTIME_EXCEPTION (in both times where this macro is used) > > 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). ------------- PR: https://git.openjdk.java.net/jdk/pull/2056
