Re: CNI & Exception handling

[Bryce McKinlay <mckinlay at redhat dot com>]

Andrew Haley wrote:

> > >The obvious solution is to have a layer that catches C++ exceptions
> > >and returns appropriate flags.  Another layer, separately compiled,
> > >can throw Java exceptions.
> > 
> > Do you have an idea of how difficult it would be to relax this
> > restriction? Would it be possible to, say, only allow one type of
> > exceptions to be *caught* in a given compilation unit? Or, could we
> > make libgcj's personality routine handle C++ exceptions as well
> > (for CNI code)?
>
> Great question!  I don't know.  I think it would be possible to have
> mixed exceptions.
>
> > Currently, this does seem like a pretty nasty limitation for CNI.
>
> I appreciate that there is some additional overhead, but it's pretty
> small.  Imagine the case where C++ throws foo_exception and the
> wrapper catches foo_exception and propagates it as FooException.  The
> additional cost of testing a flag and passing it back would not be
> great compared with the whole business of unwinding and allocating a
> FooException.  
>  
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, when all you 
want to do is call a C++ function that might throw an exception.

This "mixed exceptions" restriction also prevents using the STL (or, 
parts of it at least) in CNI code, because the STL contains exceptions 
code in headers that get inlined.

I think this is something that we should look at fixing in the future - 
I'll file a PR.

Regards

Bryce