Re: _Jv_AttachCurrentThread vs unhandled exceptions

[Cedric Berger <cedric at wireless-networks dot com>]

Bryce McKinlay wrote:

> But this leads to the question of what should happen if you attach a
> thread and then an exception is thrown but not caught. Right now the
> entire runtime will abort which seems like the wrong thing.

Yep.

> We could
> insist that those using CNI wrap any Java calls from an attached
> thread with a default try/catch block (or alternatively use the
> variant described above), but what about JNI? What is the JDKs
> behaviour if some native code invokes the VM but a Java call throws an
> unhandled exception?

Here is the part of the "java" launcher that invokes the main method.
It's self-explanatory, I guess.

    /* Invoke main method. */
    (*env)->CallStaticVoidMethod(env, mainClass, mainID, mainArgs);
    if ((*env)->ExceptionOccurred(env)) {
       /* Formerly, we used to call the "uncaughtException" method of the
          main thread group, but this was later shown to be unnecessary
          since the default definition merely printed out the same exception
          stack trace as ExceptionDescribe and could never actually be
          overridden by application programs. */
      (*env)->ExceptionDescribe(env);
      goto leave;
    }

So if an exception is thrown when you call java code from native
code, it should set some kind of "exception flag", which can be
checked by the C code.

> It seems like we need a way to set up a default exception handler
> without having to have a try/catch block around the top level of calls

>From to code below (and the comment!) the JNI native code has to
call the "default exception handler" explicitely if this needs to be done.

JNI Exception docs:
http://java.sun.com/j2se/1.4/docs/guide/jni/spec/design.doc.html#770

Cedric