> I'm afraid I don't understand: why can't you just call some sort of member
> function like:
> bool frame::throwException(java_object *);
> or
> bool java_thread::throwException(java_object *);
>
> It would unwind the frame stack to the "right" frame (based upon either an
> explicit exception stack or a traversal of the frames). frame::runOpcode would
> simply return "true" to indicate that the thread should continue execution. The
> next java_thread::runOpcode calls currentFrame()->runOpcode(), and you get the
> "right" frame. (I'm presuming that exception handlers are simply different PC
> locations within a given frame -- right?) I'm thinking this will All Just Work.
Maybe an example is necessary: I'm three frames deep in a JVM
call, say I'm doing getClass(), which throws a NoSuchClassDefinition
exception. I /can/ call thread::throwException( NoSuchClassDefinition ),
and all the java-specific things would happen, but, here's the kicker:
case bc::some_bytecode:
...
jc = getClass();
...
op_stack.push( jc->fields[x] );
break;
...
return true;
How does the code AFTER the getClass() call know NOT to push
something on the op_stack after getClass() throws an exception? I do NOT
want to rewrite every single function call in the JVM to (a) check all of
/its/ calls for exceptions and abort back to runOpcode() (which will in
turn, have to abort) and (b) return true or false depending on if an
exception was thrown or not. It's doable now, but it won't be in the
future: native methods that throw exceptions need to be handled (unravel
the native stack same as I mentioned in the last email for intra-JVM
throws); the native portion of the class library (classpath?) is where you
can't get around exception-handling in native methods. (Rewriting the
classlibrary is a heroic effort and Not The Right Thing To Do, either, I
think.)
It is difficult but doable to arrange for the native exception to
be converted into a java exception and have the necessary things happen to
the thread's data structures -- the tremendous difficulty is in aborting
the rest of the call(s), all the way back to where the scheduler can move
on to the next timeslice. It seems to me that we'd be re-writing C++'s
exception codes by hand; further, it seems evident to me that the Right
Way to handle exceptions in native code is with native exceptions, which
would all be trapped and converted in runOpcode().
Am I being clear about the problem here?
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
