Re: CNI & Exception handling

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > 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, 

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.

> 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.

Indeed.  Mind you, I've never been wild about the idea of combining
the memory management of STL with the garbage collection of Java,
although I suppose it should work.

Andrew.