docs/technotes/guides/jni/spec/design.html

@@ -646,33 +646,44 @@
 <p>In all other cases, a non-error return value
 guarantees that no exceptions have been thrown.</p>
 
 <h3><a name="asynchronous_exceptions">Asynchronous Exceptions</a></h3>
 
-<p>In cases of multiple threads, threads other than
-the current thread may post an asynchronous exception. An
-asynchronous exception does not immediately affect the execution of
-the native code in the current thread, until:</p>
+<p>One thread may raise an asynchronous exception in another thread by calling
+the <code>Thread.stop()</code> method, which has been deprecated since Java 2
+SDK release 1.2. Programmers are strongly discouraged from using
+<code>Thread.stop()</code> as it generally leads to an indeterminate application
+state.</p>
+
+<p>Furthermore, the JVM may produce exceptions in the current thread without
+being the direct result of a JNI API call, but because of various JVM internal
+errors, for example: <code>VirtualMachineError</code> like
+<code>StackOverflowError</code> or <code>OutOfMemoryError</code>. These are also
+referred to as asynchronous exceptions.</p>
 
+<p>Asynchronous exceptions do not immediately affect the execution of the native
+code in the current thread, until:</p>
 
 <ul>
-<li>the native code calls one of the JNI functions that could raise
-synchronous exceptions, or</li>
-<li>the native code uses <code>ExceptionOccurred()</code> to explicitly check for
-synchronous and asynchronous exceptions.</li>
+  <li>the native code calls one of the JNI functions that could raise synchronous
+    exceptions, or</li>
+
+  <li>the native code uses <code>ExceptionOccurred()</code> to explicitly check
+    for synchronous and asynchronous exceptions.</li>
 </ul>
 
+<p>Note that only those JNI functions that could potentially raise synchronous
+exceptions check for asynchronous exceptions.</p>
 
+<p>Native methods should insert <code>ExceptionOccurred()</code> checks in
+necessary places, such as in any long running code without other exception
+checks (this may include tight loops). This ensures that the current thread
+responds to asynchronous exceptions in a reasonable amount of time. However,
+because of their asynchronous nature, making an exception check before a call is
+no guarantee that an asynchronous exception won't be raised between the check
+and the call.</p>
 
-<p>Note that only those JNI function that could
-potentially raise synchronous exceptions check for asynchronous
-exceptions.</p>
-
-<p>Native methods should insert <code>ExceptionOccurred()</code>checks in necessary places (such
-as in a tight loop without other exception checks) to ensure that
-the current thread responds to asynchronous exceptions in a
-reasonable amount of time.</p>
 
 <h3><a name="exception_handling">Exception Handling</a></h3>
 
 <p>There are two ways to handle an exception in
 native code:</p>