Don't abort the whole process if we see a Rust panic

[rib]

PR #68 introduces an abort_on_panic wrapper to ensure that a panic in Rust can't unwind over an FFI boundary, since that leads to undefined behaviour.

A problem with this solution though is that an Android Activity doesn't necessarily own the entire process, in case there may be other Services or even Activities running in the same process in separate threads and so we're potentially tearing down more than should be necessary by aborting the whole process.

[notgull]

The proposed solution to this is to raise a JNI exception. However, my main concern is if this is safe to do from the Rust calling context, since it may cause the stack to unwind with unpredictable results.

[rib]

I'm not sure what kind of unwind you're thinking of with "may cause the stack to unwind with unpredictable results".

This would be for functions that are being called as native methods by the JVM (Activity methods like onCreate, onPause, onStart...). JNI can be (safely) used to throw an exception from the native side of the method call and the JVM will pick that up and it becomes a Java exception: https://docs.rs/jni/latest/jni/struct.JNIEnv.html#method.throw

On the Rust side we can still use catch_unwind to ensure a panic can't unwind over the JNI boundary, it's just that instead of aborting the process we'd call a JNI API to let the JVM know about an exception before returning from the native method back to Java.

There shouldn't be any uncontrolled unwind on the Rust side, and the Java exception should be controlled too?

The things I'm not sure about with this though are:

• Do we know that the exception will destroy the activity
• What re-entrancy concerns are there - e.g. what if the Java code handling the exception ends up calling Activity lifecycle methods like onDestroyed which might call back into android-activity.

I was also pondering calling Activity.finish(), although that would also raise similar questions around lifecycle callbacks.