On Thu, 7 Jan 2021 00:35:27 GMT, Sergey Bylokhov <s...@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?

But then "env" would need to be passed explicitly. I don't think the churn is 
worth it.
And a method would then need a .m or .c file ...

> 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.

I don't think "most" of the time is very likely. JNI lookup failures don't 
cause exceptions to be thrown.
Is that what you are tihinking ?

And separately, with either the current code of clearing exceptions or the 
change here to  the practice of throwing NSException on seeing a Java Exception 
I think it very unlikely.

> 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.

In my testing that code does not get called.  The new code does. So the old 
code could probably be deleted as useless but it is also harmless and just 
maybe it'll catch something else, even if it isn't doing anything that I can 
see.

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

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

Reply via email to