Status Quo:

• Any exception in JNI would be thrown as JniException. Since resource management of references is hard with exceptional control flow, we serialize the exception message and stack trace into a string and throw it as a single type JniException in dart.

Problems with this approach:

• It's hard to catch specific exception in this way. Let's say I only want to catch IOException, there's no way to do this except inspecting the string representation.
• Some exception types carry additional information along with the message, which will be lost.

Implementation options

1. Exceptions as first-class JNI objects:

   • Map each Exception to a JObject subclass, as we did before.
   • keep a central registry at package:jni which maps qualfiied name (FQN) of Java Exception types to their constructors. This is required because we must decide the type of JThrowable when we are rethrowing it in Dart.
   • Provide convenience methods to obtain stack trace.

2. Generate marker exception classes which correspond to Java exception types.

   • These are not JObject subclasses, and hold no JNI references. Can directly subclass current JniException. All functionality would be in JniException, and subclass is just a marker.
   • But still need a central registry to look up the FQN of the exception object and throw appropriate type.
   • Pro: resource management. Con: lose access to specialized methods of few exception types.