CNI & Exception handling
Tue Aug 24 23:30:00 GMT 2004
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
> > 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.
More information about the Java