The Java Native Interface (JNI) - JavaTech: An Introduction to Scientific and Technical Computing with Java - page 619

However, it is not safe to ignore exceptions, expecting the JVM to handle them.
It is possible that an unhandled exception in native code could lead to corruption
in the native code or in the JNI subsystem itself, leading to a system crash before
the native code has a chance to return. Properly dealing with exceptions inside
the native code is very important.
22.10.1 Exceptions raised by JNI functions
Whenever a JNI function must allocate memory, there is always the chance
that insufficient memory is available from the operating system, resulting in an
OutOfMemoryError condition. We have also seen an ArrayIndexOutOf-
BoundsException raised by the array functions when a region or element is
requested that is beyond the bounds of the array being accessed, and a few other
exceptions from the GetFieldID() and GetMethodID() functions. In all
these cases, the JNI system itself raises the exception.
In the case of the array functions, recall that Java keeps track of array lengths
inside an array object. When a native method calls one of the JNI array handling
functions, the Java array objects are accessed by (opaque) JNI system code that
implements the JNI function. That code takes care of checking the array bounds
and throwing the exception, if necessary. Similarly, if the GetFieldID() or
GetMethodID() method cannot find the requested field or method, then JNI
system code raises the exception. (When referring to exceptions in JNI we have
been using the terms raises and throws almost interchangeably. There is, however,
a subtle difference, which is explained below.)
Most JNI functions are declared to return values of some type. When an excep-
tional situation arises, most functions can return a special value, usually NULL ,
known as an error code. (This is quite different from Java-side programming
in which error code returns are almost never used.) In fact, most JNI functions
report an error condition by returning an error code and raising an exception.
Therefore you can check for the error code value to know whether or not an
exception has been raised. The error code for each JNI function is documented
in the JNI Specification [1]. If the documented error code is not received - i.e. if
avalid value is returned rather than the special error code value - then one can
be certain that no exception has occurred.
However, there are a few situations where the JNI system does not return a
special error code, meaning that if an exception occurs, the only way you can
know about it is by explicitly checking for the presence of an exception. One
such situation is when a JNI function is used to call a Java method. In that case,
the JNI function must return the result of the Java method. If that Java method
throws an exception, there is no special error code value for which to check.
Another case is with certain JNI array functions that do not return error codes
but instead raise exceptions such as ArrayIndexOutOfBoundsException
or ArrayStoreException .