Add rules about documenting JNI exceptions.

PiperOrigin-RevId: 609457790
Change-Id: Iede3daee092513615276670de06d79094bed3a59

1 files changed, 11 insertions, 0 deletions

diff --git a/api-guidelines/ndk.md b/api-guidelines/ndk.md
index 66fb6e0..873e36a 100644
--- a/api-guidelines/ndk.md
+++ b/api-guidelines/ndk.md
@@ -313,6 +313,11 @@ the NDK documentation. **API authors do not need to manually update DAC.**
     number instead of the codename since that's what users need to know for
     their build.gradle files. Non-NDK APIs should consider doing this as well.
 
+8.  Potential pending exceptions should be limited to runtime issues such as
+    `OutOfMemory``or`ClassCastException`` unless clearly documented what the
+    other potential exceptions are and why they may occur (see also:
+    go/android-api-guidelines#throws )
+
 ## ABI stability guidelines <a name="abi-stability"></a>
 
 ### Prefer opaque structs <a name="opaque-structs"></a>
@@ -563,6 +568,12 @@ and
 
 This helps apps to keep a clean JNI layer in their own code.
 
+### JNI interop APIs should not clear pending exceptions
+
+Any exceptions thrown should be left pending for the caller to handle. Most
+potential pending exceptions types must be documented. See
+go/android-ndk-api-guidelines#well-documented.
+
 ## Inlines <a name="inlines"></a>
 
 ### Inline functions may be used for simple wrappers <a name="inline-wrappers"></a>