CNI & Exception handling

Andrew Haley
Tue Aug 24 15:22:00 GMT 2004

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > >RamrajPrabu Balasubramanian writes:
 > > >
 > > >       The project I'm working on involves writing CNI wrappers to existing 
 > > > c++ classes that we have. the problem is these c++ classes throw exceptions 
 > > > and there are a lot of them. I know catching c++ exceptions and rethrowing 
 > > > them as java exceptions casuses the " mixing java and c++ exceptions in same 
 > > > translation unit is not  allowed" error.
 > > >       Getting past this hurdle is very important for us to adopt gcj in our 
 > > > projects, can some one suggest some ways to handle these c++ exceptions 
 > > > without changing our existing c++ code ?
 > >
 > >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

I suppose the greatest pain is in the "normal" return path where no
exception is thrown.  Still fairly small, though.

This stuff is all pretty much boilerplate.  The nicest thing might be
to auto-generate the CNI wrapper from a C++ specification.


More information about the Java mailing list