Re: Can't pass exceptions with Java 7 : java.lang.Throwable.suppressedExceptions

On May 14, 2012, at 10:54, Thomas Leonard wrote:

> With Java 7, Throwables can no longer be sent successfully over CapTP. The error is:
[...]
> captp: whyNoDeliverOnlyOp(4, run, java.lang.ClassCastException: cannot  assign instance of org.erights.e.elib.ref.OldFarRef to field java.lang.Throwable.suppressedExceptions of type java.util.List in instance of java.lang.ClassCastException)
[...]
> The problem seems to be the new list of "suppressed" exceptions attached to each Throwable:
> 
> http://docs.oracle.com/javase/7/docs/api/java/lang/Throwable.html#getSuppressed%28%29
> 
> CapTPReplacer turns this into a far ref (presumably on the assumption that the list may be mutable), but the Throwable created at the destination needs a List, not a far ref.
> 
> I assume there's some mechanism to handle things like this (since getStackTrace(), which also returns an array, works fine).

The E-on-Java runtime assumes that arrays it encounters are used as if they are immutable, and treats them as equivalent to ConstLists. Note that getSuppressed returns an array; the problem here would seem to be (from your description) that Throwable uses a List rather than an Array in its *serialization* only.

> This hack fixes it, but I'm not sure it's right in general ("unmodifiable" seems to mean "read-only" rather than "const"):
> 
> (in CapTPReplacer.substitute)
> 
> if (ref.getClass().getName().equals("java.util.Collections$UnmodifiableList")) {
> 	return null;
> }

Indeed, this would seem to be wrong-in-general insofar as a RO list might be used elsewhere. However, E code should not in general be using Java collections directly, so that would be OK except for the ELib-as-Java-library aspect.

Is there any possible way we could specially treat UnmodifiableList iff it is being serialized from inside the serialization of a Throwable?

> Suggestions?

Well, in the long run we want to replace JOSS with Data-E, so this is a temporary workaround anyway.

What I would do is write or modify a replacer to recognize Throwables and serialize them into E-friendly parts.

However, we have the problem of creating appropriate subclasses rather than generic Throwable/Exception/etc.

However-again, right now we have no way of defining exception types from within E, which is another bug to fix and affects what-is-right here. This is noted at <http://wiki.erights.org/wiki/Exception_types>. I have a prototype of user-defined exceptions, which keeps exceptions strictly as generic objects with exception-types being data stored in fields on them, but I don't recall whether I've published it.

These are my initial thoughts on the matter; please do refine, nitpick, and question.

-- 
Kevin Reid                                  <http://switchb.org/kpreid/>