Exception transparency - lone throws (no checked exceptions)

[Stephen Colebourne]

On 10 June 2010 21:00, Alex Buckley <alex.buckley at oracle.com> wrote:
> Exception transparency is about abstracting over the types of checked
> exceptions that can be thrown by a method.

That statement appears to conflate two requirements.

My understanding of the exception transparency requirement is to
permit an exception thrown in a block of code (SAM/lambda) to
transparently pass through the controlling method (that invokes the
closure) and arrive back at the call-site as the same exception.

AFAICT, this proposal achieves that.

However, you appear to be raising the bar beyond the core requirement,
by adding a separate requirement to be able to pick and choose which
exceptions are thrown and which aren't. I fail to see as to why that
is anything to do with /transparency/. I'd call that feature "generic
exception control" or some other name - ie. a separate requirement.

Its certainly a requirement/feature with power, and some would find it
useful, but I claim that the cost far outweighs the uses.

Another way to view it is the 80/20 rule - my proposal solves 80% of
cases with 20% of the complexity. (actually its probably 98/2 rather
than 80/20).


> This proposal is not about exception transparency. This proposal is about
> _ignoring_ the checked exceptions that can be thrown by a method.

Yes, I have chosen to couch the proposal in a manner broader than just
restricting it to the narrow problem of Project Lambda. I think thats
a Good Thing. Reinier outlined 4 ways that this occurs today anyway,
so this simply acknowledges reality.

The proposal could be restricted to only applying to lambda function
types and methods receiving them, but that would be more confusing and
less helpful.

> So, this proposal is about allowing checked exceptions to be turned off. And
> turned off in a very specific way: as per your response to Peter, if the
> caller doesn't care to catch anything from a 'lone throws' method, then the
> "checked" exception propagates up the call chain, and may be caught
> somewhere via a new 'lone catch' mechanism. Basically the same as wrapping
> checked exceptions in RuntimeExceptions, as proposed by
> http://bugs.sun.com/view_bug.do?bug_id=6534270.

That proposal involves wrapping in RuntimeException - I don't support
that at the language level. Plus, it is unnecessary - the JVM permits
throwing any exception. Checked exceptions are mostly just a figment
of the compiler's imagination. This proposal simply takes away a
restriction in a controlled manner, bringing Java closer to every
other language on the planet.

> While I'm not especially fond of all the machinery around exception
> transparency, exception transparency _is_ what we want to provide.

And the proposal provides it. In my view, you are following an avenue
to achieve a second requirement.One that is more powerful, but one
that has too high a price.

Seriously - please just look at what the strawman proposal looks like
in this area!! Java overstepped the bounds of acceptable
type-information with wildcards. The strawman exception transparency
is type-signature noise to the extent of wildcards mark 2 !

Stephen