Re: CNI & Exception handling

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:

> > Sure, the overhead is not so much of a concern, but rather
> > ease-of-use.  Its pretty painful for a developer to have to create
> > a whole new C++ source file with its own functions, then define
> > special return values for the exceptional cases, and write code to
> > rethrow them, 
>
> Yeah, you're totally right.  It wasn't clear to me where the pain you
> described was -- the run-time overhead or the difficulty for
> developers.
>
> > when all you want to do is call a C++ function that might throw an
> > exception.
>
> Well, let's say we do allow exceptions types to be mixed in a CNI
> program.  You're still going to need to define a Java exception class
> to re-throw a C++ exception, even if it's only a wrapper.
>  

Well, you might not necessarily want to re-throw. You might take some 
other action, or just want to catch some C++ exception to stop the 
application aborting due to not being able to find a handler!

It turns out the problem here is really "cant catch C++ exceptions in 
CNI code". Throws can be mixed fine, apparently. This is because we 
define "#pragma java_exceptions" in the cni headers - once the C++ 
compiler sees that, only Java catches are permitted.

From a brief look at the C++ front end code, it seems that the only 
thing that the "java EH model" actually does is change which personality 
routine is called. So, perhaps all we need to do is make sure libgcj's 
personality routine can deal with C++ exceptions, or have it check 
unwindHeader.exception_class and have it call through to the C++ routine 
via a weak reference if a C++ exception is seen.

Bryce