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

On 2012-05-14 17:35, Kevin Reid wrote:
> 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.

Good points. Having custom logic for Throwables seems OK (since the code 
already special-cases Throwable in JOSSPassByConstruction.HONORARY).

Losing the exception type seems OK to me, since it fits in with the general 
E idea of exceptions not having interesting types. And in fact, I usually 
turn all exceptions into RuntimeException if they might go over CapTP, since 
the receiver often doesn't have the exception type in its classpath.


-- 
Dr Thomas Leonard
IT Innovation Centre
Gamma House, Enterprise Road,
Southampton SO16 7NS, UK


tel: +44 23 8059 8866

mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk/