> Yes you do. You do want every caller be able to tell if functions it
> called have aborted or are aborting. Without fail, you will define
> functions that need to execute special code for handling failures.
Every caller /should/ be able to catch exceptions that /might/ be
thrown by the callee and otherwise let it be handled by the default C++ ->
Java exception converter, which it will probably call anyway. But this
p.o.v. might be too strongly influenced by Java.
> Originally, Kaffe would throw exceptions from deep within native code
> and these exceptions would correctly unwind the native stack all the
> way back into Java code, and proceed from there looking for exception
> handlers. This worked fine in most cases. (As an aside, Kaffe uses
> the same stack for Java and native code.)
To my understanding, this is precisely the approach that I /can't/
take because of the limitations in JJOS. (As an aside, decaf doesn't use
the same stack because it caused problems with preemption of threads --
which might not exist under an OS more advanced than JJOS.)
> We opted for explicit returns codes.
This seems to be somewhat wiser than rewriting C++ exceptions by
hand in C, which is what the option sounded like.
> > the native portion of the class library (classpath?) is where you
> > can't get around exception-handling in native methods.
>
> That is, calls into native functions like FileInputStream.read()
> should be able to just directly throw exceptions that will unroll the
> native stack like they unroll the java stack.
>
> We decided (err, Godmar Back who designed/implemented this for Kaffe,
> decided) to make all VM internal functions return an integer status
> code and take an exception description struct.
...sigh... This is exactly the same massive rewrite that I had
started this message-thread trying to avoid. But it doesn't look that's
going to happen, does it?
> I hope this helps some,
Thanks. I should have guessed that other JVM efforts have tackled
this problem, but it's good to get the justification as well as the
result.
-_Quinn
_______________________________________________
Kernel maillist - [EMAIL PROTECTED]
http://jos.org/mailman/listinfo/kernel
