RFR: 8259343: [macOS] Update JNI error handling in Cocoa code.

[Sergey Bylokhov]

On Wed, 6 Jan 2021 21:14:06 GMT, Phil Race <prr at openjdk.org> wrote:

> Proposed updates to JNI error handling.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 180:

> 178:  * nature of the problem that has been detected and how survivable it is.
> 179:  */
> 180: #define CHECK_EXCEPTION() \

Since this macro does not try to return from the outer code we can change it to the method?

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 182:

> 180: #define CHECK_EXCEPTION() \
> 181:     if ((*env)->ExceptionOccurred(env) != NULL) { \
> 182:         if ([NSThread isMainThread] == YES) { \

Isn't it is a similar code to the
https://github.com/openjdk/jdk/blob/67c221148159d94142a3a6d9ddadce2dff8c858b/src/java.desktop/macosx/native/libosxapp/NSApplicationAWT.m#L334
Where we just catch an exception log it, and continue to run our infinite loop? Why do we need to do something specific here? I mean we cannot drop any try/catch blocks anyway since an nsexception may be generated by some external system code.

src/java.desktop/macosx/native/libosxapp/JNIUtilities.h line 41:

> 39:        NSLog(@"%@",[NSThread callStackSymbols]); \
> 40:        if ([NSThread isMainThread] == NO) { \
> 41:            JNU_ThrowInternalError(env, "Bad JNI Lookup"); \

It will be possible that(most of the time) the JNU_ThrowInternalError will be called while we already have a raised java exception.

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

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