This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proxying between C++ exceptions and Java ones


On Fri, Mar 04, 2005 at 04:55:12PM -0700, Tom Tromey wrote:
> Waba> I could of course make another proxy for this class, that catches any
> Waba> C++ exception and uses return codes instead, but that isn't very nice,
> Waba> especially since the Java class is already some kind of proxy to the C++
> Waba> class. Is there any clever way ?
> 
> Given that arbitrary C++ exceptions aren't easily representable in
> Java, you probably just want to catch them and then throw some Java
> exception (or ignore them).  In that case, I think this ought to work:
It could be useful to provide the Java caller/user with a tad more info,
especially if the C++ code is known to throw an exception upon receiving
invalid arguments. Something like typeid().name() and exception.what()
could do the trick (and/or a similar exception hierarchy in Java).

>     try {
>       random_cxx_function();
>     } catch (...) {
>       throw new SomeJavaException();
>     }
This compiles, but doesn't achieves the expected effect, because the
said pragma forces the catch (...) to work for Java exceptions only.
As a result, my exception isn't caught here, and the stack keeps
unwinding until reaching whatever called the Java code (such as gij)
and finally std::uncaught_exception().

> Waba> However, <gcj/javaprims.h>, included from any java header, contains
> Waba> the #pragma GNU java_exceptions, actually forcing the Java-Exc mode
> Waba> inside any CU that handles Java objects. Commenting out this line makes
> Waba> my trivial test program work perfectly, although this doesn't mean
> Waba> anything.
> 
> I think you need this line if you want to actually catch Java
> exceptions in your CNI code.
I'm not so sure of that... From the gcc sources and documentation, it
selects it according to the first occurence of one of:
 - #pragma GNU java_exceptions
 - catch clause, depending on the caught type
and of course, if one of those is met later, it must confirm this
choice. (A quick test confirmed this).

I can now see a big reason of why this line exists: handling the bad
guesses (that would end up with a link error) as explained in
http://gcc.gnu.org/onlinedocs/gcj/Exception-Handling.html . This is
nice, however unless I'm missing something, it is also preventing valid
code (mine) to compile. Not a big deal to modify this header on my
computer, but it gets messy if I want to distribute my code :-)

What I would suggest (assuming this is the only reason), is to either
remove or (more conservative), #ifndef it, so that RTFMing allows
compilation of code such as mine. I have found a similar problem in bug
5103, which was closed three years ago.

TIA,
-Waba.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]