Re: Question about EH

[Mike Stump <mrs at windriver dot com>]

> Date: Wed, 23 Feb 2000 11:26:14 -0800 (PST)
> From: Tom Tromey <tromey@cygnus.com>
> To: Mike Stump <mrs@windriver.com>

> >>>>> "Mike" == Mike Stump <mrs@windriver.com> writes:

> Tom> Currently, you can't `catch' a Java exception in a C++ function

> Mike> Well, this is a java issue.  If you want to find the g++
> Mike> entries, you will need to figure out a mapping between C++ and
> Mike> Java that you like, and extend the Java matcher to handle the
> Mike> union case better.

> I don't see how we can do this.

I do.  I can elaborate some:

in catcher type matcher:

    If lang of EH object is C++,
        run object converter for object to import into Java system

then normal Java rules, or you can extend the Java type system to
include more C++ types in it, and extend the allowable types that can
be thrown to include these types and extend the matcher to know about
these types, and presto...  interworking.

Please state the next problem you think can't be solved, and I can try
and solve it...

> Per (I think) added Java type support to the C++ compiler.  Java
> objects are a lot like C++ objects, but they aren't the same in every
> respect.  For instance, Java objects don't use the C++ notion of RTTI
> -- Java has its own way of doing this.

> If I have a pointer to a random collection of bits (which is what I
> have in the type matcher, I think), I don't think that there is a way
> to determine whether it is a C++ object or a Java object.

If it is a Java compatible type and uses the Java way of denoting it,
then it makes sense to say that the language it was thrown from was
Java, even though it was C++.  Then, the java matcher `sees' a normal
Java object and it all just works.

Another way would be to include information that denotes this aspect
of type in the typeinfo stuff.  Java then can then do:

    if lang of EH object is C++
        and EH object is a Java compatible object
        do normal Java matching

Either way will work, though I prefer the first.

> Mike> If you start small "i" (the mangling for the `int' type in
> Mike> C/C++), and just catch those in java (from a throw 1; in C++),
> Mike> you will get a feel for it.

> This is the start of the impossible things.

I fail to see how you could fail to convert 1 to some random throwable
object in the Java runtime.  Please explain why you cannot have a
random class, and why that class cannot have a 32 bit integer in it.

Now, you may _choose_ to exclude throw 1; in C++ from interworking
with Java.  That is fine, and in that case, you don't need to worry
about it, or you can make it work.  If it is to work, then you can
either transcode the EH object into a real (proper) Java object, but
this transformation is non-obvious, non-standard, and will have to be
documented as a gcc extension and the mapping explained for the user
to use, or you can extend java to handle the `type' int in a more
natural way, directly, but again even in this case, it is still a gcc
extension.

> In Java it is only possible to throw a Java object derived from
> java.lang.Throwable.

Ok, inherit from that if that is what you want to do.  I don't see the
problem.

> Date: Wed, 23 Feb 2000 13:55:26 -0800 (PST)
> From: Tom Tromey <tromey@cygnus.com>
> To: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>

> >>>>> "Martin" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

> Martin> Therefore, to catch exceptions thrown in Java, you need to put
> Martin> a C++ typeinfo into the exception info. I'm not sure whether
> Martin> the C++ compiler generates proper typeinfos for 'extern
> Martin> "Java"' classes; that also may need some work.

> It does not.  In fact, you have to compile native methods (written in
> C++) with -fno-rtti.

:-(  Hum...  in time this will be fixed...

> I don't know why this decision was made.  I definitely don't know all
> the issues.

Easy of implementation, and getting something working I suspect.

> Martin> Of course, it may be possible to adjust everything the other way
> Martin> 'round, ie. treat throw and catch in C++ specially if that is an
> Martin> extern "Java" type.

> That's the approach I'm currently taking, because I understand it.

Actually, I think this is a great approach, as C++ already has a
notion of extern "Java" that can be used to do just about _anything_
you want to do.  It keeps things in Java a bit cleaner.

The next issue is interoperability with C!  For it, there isn't an
extern "Java" yet, so you may be forced into transcoding.  Oh, and
kenner can help you interoperate with Ada after that!  ;-P