Or a suppressed exception. Mike
On Feb 25 2014, at 06:14 , Roger Riggs <roger.ri...@oracle.com> wrote: > In some cases, I would expect that the exception being overridden > would/should become the 'cause' of the new exception so it is not cleared > but chained. Does JNI support that? > > On the original issue, discarding of exceptions should be explicit not > implicit. > Keep (or insert) the exceptionClear(). > > Roger > > On 2/25/2014 6:35 AM, Chris Hegarty wrote: >> >> >> On 25/02/14 11:26, Petr Pchelko wrote: >>> Hello, Alan. >>> >>>> I can see how this might be attractive but doesn't it mean you are >>>> suppressing an important exception? >>> In case we’ve already got into the JNU_Throw we will throw a new exception >>> and override the original one anyway. However I agree that this might >>> suppress the warning for the code analysis tools. >>> >>>> Are the examples that you are looking at along these lines? >>> There are a number of examples when JNU_Throw is used to: >>> 1. Replace the message of an original exception: >>> src/share/native/sun/awt/image/awt_ImageRep.c:192 >>> There are a few such places. >>> >>> 2. Rethrow some meaningful exception if the call to some function failed: >>> src/windows/native/sun/windows/awt_Window.cpp:2861 >>> This is a much more common use case. In this case we have a return code >>> from some method and we do not care if it was failed because of JNI >>> exception or for some other reason. This is the main case where we need to >>> add env->ExceptionClear() everywhere. >>> >>> 3. Quite common is to use it in the initIDs method to rethrow >>> NoSuchFieldError: src/share/native/sun/awt/image/BufImgSurfaceData.c:77 >>> This one is questionable, I think that rethrowing is not needed here at >>> all, the original exception is much more informative. >> >> Agreed. Similar to NetworkInterface.c Line:172 >> >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/6ee5c47bdba7/src/solaris/native/java/net/NetworkInterface.c#172 >> >> >> -Chris. >> >>> 4. Where currently are throwing an exception with pure JNI, but it could be >>> replaces with JNU: src/windows/native/sun/windows/awt_PrintJob.cpp:1365 >>> Similar to #2. >>> >>> With best regards. Petr. >>> >>> 25 февр. 2014 г., в 2:42 после полудня, Alan Bateman >>> <alan.bate...@oracle.com> написал(а): >>> >>>> On 25/02/2014 10:31, Petr Pchelko wrote: >>>>> Hello, Core and AWT teams. >>>>> >>>>> In AWT we have a lot of pending exception warnings which are now being >>>>> fixed. A big fraction of this warnings is about a pending JNI exception >>>>> at a call to JNU_Throw*. >>>>> Why don’t we add an env->ExceptionClear() call in the beginning of each >>>>> JNU_Throw function? It is absolutely safe because: >>>>> 1. We are rethrowing an exception an loosing the original one anyway. >>>>> 2. In case there’s no pending exception the ExceptionClear is a no-op. >>>>> >>>>> If we do this the code would become much cleaner, because currently we >>>>> have to manually clear a pending exception before every call to >>>>> JNU_Throw*. >>>>> >>>>> What do you think about this proposal? >>>>> >>>> I can see how this might be attractive but doesn't it mean you are >>>> suppressing an important exception? We've fixed many areas in the last few >>>> weeks and I think a common case was just that whoever wrote the original >>>> code didn't realize that some JNI functions having a pending exception >>>> when they fail. In those cases then often it is a simple matter of just >>>> returning from the JNI function (maybe after some clean-up). Are the >>>> examples that you are looking at along these lines? I guess I'm mostly >>>> interested to know whether the JNU_Throw usages are needed or not. >>>> >>>> -Alan. >>> >
