Re: Question about EH

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> 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

That seems to postpone the problem. How does the object converter work?

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

The C++ compiler currently calls cp_push_exception, no matter
what. That always says that it is a C++ exception. Because you have to
compile with -fno-rtti at the moment, it does not even have a sensible
type_info function.

*If* the compiler was changed to throw extern "Java" classes (and
pointers thereof) as Java exceptions, then you probably also need to
declare that you are catching them as Java exception. This brings us
back to Tom's original question, of why there can be only one language
for an __EXCEPTION_TABLE__.

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

That currently won't work because the C++ compiler won't emit sensible
type information for Java classes.

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

The Java *language* does not support throwing and catching primitive
types. Of course, you could make up arbitrary rules, such as wrapping
a primitive int into a java.lang.Integer. That still wouldn't work, as
you can't throw java.lang.Integer, either - that does not inherit from
Throwable. So you'd have to make a class gnu.IntegerException to deal
with that exception. 

You can go on with supporting all primitive C++ types, although some,
of course, are tricky (unsigned int, unsigned long long). Next, what
if you throw a 'char*'? How would you wrap that into a Java object?
Or pointers to arbitrary C++ class types with no apparent Java
equivalent?

It just doesn't work in the general case, and I think there is little
point making it work in special cases.

Regards,
Martin