Exception transparency

[Alessio Stalla]

On Tue, Jun 8, 2010 at 9:16 AM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> Indeed. But how often does that happen? There are always pros and cons to be
> weighed. No one system is perfect. Brian's is unwieldy, and does not seem to
> answer a simple question - how to add exception transparency to
> Collections.sort. Mine is simpler and answers that question, but isn't
> composable.

I don't know how often it happens, but I must say that to me one of
the key points in favor of closures is the ability to compose them,
store them in variables, pass them as parameters and return them from
methods.

To me, this exception transparency problem is mainly the *checked*
exception transparency problem; unchecked exceptions do not exhibit it
(unless they are caught by the method calling the closure, as in
Reinier Zwitserloot's example, but that is a problem in any case). So,
speculating wildly, what if:

a) closures wrap all exceptions (or just checked ones?) thrown from
their body in an unchecked final ClosureException<E>. This is done
automatically by the compiler, which also makes sure that type
variable E is assigned CheckedException1|...|CheckedExceptionN
depending on the exceptions that can escape the body of the closure,
and ties this information to the type of the closure (which then is,
say, #foo(bar, baz, ...) throws ClosureException<A|B|C>). You can only
assign a closure with type ...throws CE<A|B|C> to a variable with the
very same throws clause, or with a throws clause with a common
supertype of A, B and C (Exception is thus always valid).
b) ClosureException has a "special" (native?) method unwrap() which is
final and which is known by the compiler to throw one of the checked
exceptions specified in the generic type variable of ClosureException
c) optionally, unwrapping could be done automatically, but I'm not
sure about this one. If it's done, you need a way to tell the compiler
not to unwrap, in case you want to propagate the exception to the
caller (as it is the case for utility methods such as
Collections.sort)

Does this make any sense?

Cheers,
Alessio