The JNI spec. seems to be inaccuratate and is leading to some confusion in the field.
JNI spec.....
http://java.sun.com/j2se/1.3/docs/guide/jni/spec/design.doc.html#770
"Exception Handling
There are two ways to handle an exception in native code:

    * The native method can choose to return immediately, causing the exception to be thrown in the Java code that initiated the native method call.
    * The native code can clear the exception by calling ExceptionClear(), and then execute its own exception-handling code.

After an exception has been raised, the native code must first clear the exception before making other JNI calls. When there is a pending exception, the only JNI functions that are safe to call are ExceptionOccurred(), ExceptionDescribe(), and ExceptionClear(). The ExceptionDescribe() function prints a debugging message about the pending exception."

There has been discussions about this matter, and depends on the VM implementation, but we
should follow the JNI spec.
*** (#3 of 5): 2005-12-14 15:26:07 PST ###@###.###

Please see http://java.sun.com/docs/books/jni/html/design.html#2193. The spec quoted in the previous evaluation comment is incorrect and should be fixed. The attached files Test7.java and Test7.c illustrate why. For example, in Test7.c

        for (i = 0; i < n; ++i) {
                (*env)->CallVoidMethod(env, obj, jm, s, i);
                if ((*env)->ExceptionCheck(env)) {
                    (*env)->MonitorExit(env, jc);
                    return;
                }
        }

failing to call MonitorExit in the exception case hangs the application; the second thread in Test7.java never gets to run. However, including the MonitorExit call thwarts the exception handler of the first thread in Test7.java.
*** (#4 of 5): 2005-12-14 17:08:01 PST ###@###.###

See test case Test7.* in CR: 6361259