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