gistfile1.txt

MonoDroid Exception Problem

We are integrating 2 distinct VM's that do not have knowledge of one another; and each has their own exception handling mechanism.  Mono's debugger unhandled exception support works by walking the LMF's and checking if there are any call filters that would catch the exception, if there are not we pass the exception to the debugger before crashing.

MonoDroid currently implements exception interleaving by catching all exceptions at the transition point, and converting them to exceptions of the other VM type (encapsulating the pertinent information in a string, which kind of sucks).

Take the following example (psuedo-code):

zygote (java Main)
       |
fooActivity (java)
    public void onCreate () {
        mono_onCreate ();
    }
       |
fooActivity (mono)
    public void mono_onCreate () {
       try {
          ...
       } catch (System.Exception e) {
          jni_raise_new_java_exception (convert_mono_exception_to_java (e));
       }
    }

Of course the situation gets more complex as we have more interleaved frames, since we might end up calling java code from mono_onCreate which throws a java exception.

MonoTouch handles this by completely opting out of the ObjC exception handling mechanism and has no interleaved exception support at all, the only thing MonoTouch does is register a global unhandled exception handler with the ObjC runtime, and convert that to a managed exception, but this is a fatal unrecoverable exception just dumped for informational reasons.

We could follow the MonoTouch pattern here, but we become susceptible to some possible API problems since exceptions are far more "first class" in java than in ObjC.

Possible solutions:

1> Do the monotouch thing
2> Do the monotouch thing + convert all java exceptions that we jni into managed exceptions, thus trusting our unwind code
3> Figure out some way to treat the exception handling / call filter code specially for monodroid (note; I like this the least since it requires custom runtime goo we need to maintain forever)
4> ???