Exception transparency - lone throws (no checked exceptions)

[Alessio Stalla]

On Fri, Jun 11, 2010 at 7:26 PM, Neal Gafter <neal at gafter.com> wrote:
> 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.

Well, you could argue that since Java is a fully OO language (apart
from primitives), adding a functional language concept like closures
is not a plausible approach. The addition of a language feature
necessarily changes the language, and may even undermine the premises
on which the language was built. A balance must be stroke between
staying "true to Java" - almost-pure OO, type safety, checked
exceptions - and adding a new feature. The cost of staying "true to
Java" maybe is simply too high in this case.
Similar arguments could be made for reflection as well. Reflection
allows me to call a method bypassing exception type safety in a way.
But it was theoretically possible, with generics, to modify reflective
objects to encode exception information, as in Method<throws
IOException|SQLException>. Then, method.invoke would force you to
either catch or propagate IOException and SQLException. Why wasn't it
done? And why must it be done with closures? Especially today, when
more and more people are questioning the value of checked exceptions -
as I said, a player as important as Spring officially adopts the
policy of using unchecked exceptions whenever possible.

Cheers,
Alessio