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

On 2012-05-15 11:03, Kevin Reid wrote:
> On May 15, 2012, at 4:33, Thomas Leonard wrote:
>
>> 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.
>
> Just a clarification: there is certainly not a general E idea of
> *throwing out exception type information*, or rather, insofar as there
> is, it is because our exception handling is severely immature. There has
> not been enough (design response to) E application code which actually
> needs to recover from specific errors.
>
> The prototype and plans I referred to are about making exception types a
> matter of data rather than distinct classes, not about throwing out
> exception types entirely.

Right, so exceptions are considered to be data (anyone can construct any 
exception; they convey no authority).

So if I did something like:

try {
   ...
} catch ex :SQLException {
   ...
}

then there's no guarantee that "ex" really is an SQLException (the exception 
could have been generated by code with access only to safeScope). Seems 
sensible.

What changes are needed to make this all work?

- change exception guards to use __getAllegedType() for EBacktraceException 
(or whatever is used as the generic type).

- change CapTP to turn exceptions into this type

Would this be a good time to put the stack trace  / cause / supressions into 
a sealed box too?


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