Exception transparency - lone throws (no checked exceptions)

[Neal Gafter]

On Thu, Jun 10, 2010 at 6:42 PM, Reinier Zwitserloot <
reinier at zwitserloot.com> wrote:

> Alex, exception transparency is obviously not about abstracting over the
> types of checked exceptions that can be thrown by a method.Exception
> transparency is about the ability to let the handling of a checked
> exception
> thrown in a closure to be done by the containing method. As in, the
> exception handling is transparent. Exception Transparency. Unless you'd
> like
> to enshrine your particular definition as canon, but if that's the case, I
> strongly suggest you pick a different name, and add it to the official
> spec.
>

Reinier-

I'd be surprised if Alex responds to that condescending tone, so let me see
if I can add something.

Exception transparency is a primary use cases that motivates abstracting
over the throw exception types, but it is important enough a use case to use
its name to refer to the feature.  It isn't so important what we call it,
rather it is important what it does.  Assuming it is the only important use
case is an approach that leads to poor language design decisions.  See <
http://gafter.blogspot.com/2006/09/failure-of-imagination-in-language_17.html
>.

Achieving exception transparency in some APIs requires storing closures in
variables.  Since Java is a strongly typed language with checked exceptions,
the type of the variable should be capable of expressing precisely the types
of the exceptions that may be thrown when the closure is invoked.  Making
the variable weakly-typed or weakening Java's exception checking are not
plausible approaches.

Cheers,
Neal