Exception transparency - lone throws (no checked exceptions)

[Stephen Colebourne]

On 10 June 2010 19:31, Reinier Zwitserloot <reinier at zwitserloot.com> wrote:
> Stephen: I wouldn't particularly mind your proposal, personally, but it's
> effectively aborting the checked exception experiment.
As Alessio said, it doesn't go that far. It doesn't break checked
exceptions, but formalizes how they can be worked around.

And yes, many Java developers do believe in checked exceptions. This
softly, softly approach would provide a good way to wean them off the
drug.

> There's an alternative implementation which is based on
> explicitly stating the types you'd like to sneaky throw. I'm not quite sure
> how one would mesh this with the closure syntax, but it has the advantage of
> at least explicitly stating that, yes, I 'sneaky' throw IOException here.
While possible, a major goal was that function type signatures should
not include exceptions. So I rejected this option.

> However, your proposal has a flaw; I think it'll eventually boil down to
> simply getting rid of the concept of checked exceptions in general. It
> doesn't extend to SAMs, because in your system adding a "lone throws"
> changes the signature. You can add a lone throws to an interface method
> without breaking backwards compatibility as far as I can tell, but that's
> not the problem. The problem is this: *Existing* SAM classes that aren't
> updated to add a lone throws to their one abstract method CANNOT be created
> by way of the closure syntax, because closures have implicit lone throws.
During compilation, the compiler knows whether the block is being
converted to a SAM or directly to a function type. In both cases, the
block must meet the throwable requirements of the method signature
being implemented. For function types, this always has a lone throws,
so anything can be thrown. For SAMs, the compiler simply evaluates the
single SAM method and either applies the standard checked throwable
rules or the lone throws rules depending on whether the SAM has lone
throws declared.

The only problem here is that a SAM interface that isn't updated with
a lone throws doesn't support exception transparency. But that is a
relatively Good Thing as that is probably exactly what you want. (A
SAM looks like existing Java, so you wouldn't want it to magically
become exception transparent - it takes a developer decision to make
it transparent for a SAM). Note that this also helps distinguish a SAM
from a function type.

I also don't think this point is any different from the strawman, as
each SAM interface there must be updated with pig-ugly boilerplate to
support the proposed scheme.

Stephen