On Fri, 18 Dec 2020 21:57:23 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > > There seems to be a pattern where we replace `JNFCallObjectMethod()` with > > > a pair of `CallObjectMethod()` immediately followed by `CHECK_EXCEPTION()` > > > There are places where currently in this fix, this pattern is missing the > > > `CHECK_EXCEPTION()` > > > Can we replace `JNFCallObjectMethod()` by a single function call (or > > > macro) that wraps both `CallObjectMethod()` and `CHECK_EXCEPTION()` into > > > one? > > > This would make this change more robust and make it easier to review it. > > > > > > Its is a reasonable idea and I thought about it but on the whole I'd prefer > > not to do it and insted fix missing cases. > > Tthere are cases where we are using these macros directly in a native > > method and then returning to Java. > > In those case I want to propagate the exception and this suggestion would > > make that difficult if not impossible. > > I guess it should work already in the JNF case? The java exception should be > wrapped by the NSException in the JNFCallObjectMethod/etc and unwrapped in > the JNF_COCOA_ENTER before exists to the java method? That is the pattern I know is there today and I don't think is needed. It can be done but I don't think it needed. I'd prefer to see if we ever have such a situation and deal with it "locally" at the call site. > > So I believe we may end up more (theoretically) robust with my changes than > > we were before. > > Perhaps they weren't a result of a JNF* call but still it seems improved. > > I am not sure about that. I am looking at JNI warnings - not just guessing. ------------- PR: https://git.openjdk.java.net/jdk/pull/1679
