_Jv_AttachCurrentThread vs unhandled exceptions

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Ever since _Jv_AttachCurrentThread was implemented and the runtime
changed to reuse the initial thread rather than starting a new thread
to run main(), there has been a problem with uncaught exceptions
thrown from the main thread. Because there is no default exception
handling wrapper around the invocation of main(), uncaught exceptions
in thread "main" are causing the runtime to abort.

I've fixed this in my tree by adding a new interface to
_Jv_AttachCurrentThread which takes an unstarted Thread object as an
argument. After attaching, the calling code can then call
_Jv_ThreadRun (renamed from run_) to start the thread. This results in
the regular thread startup and shutdown code being run at the right
times without any duplication, which is exactly what we want, at least
for internal use within the runtime.

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. 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?

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
- ie code that will be invoked if no exception handler is found, but
still allow us to get at the exception object which was thrown? Is
that possible?

regards

Bryce