Exception transparency - lone throws (no checked exceptions)

[Stephen Colebourne]

On 11 June 2010 18:59, Brian Goetz <brian.goetz at oracle.com> wrote:
>  (This is a solution to the
> problem of exception transparency much as arson is a solution to the problem
> of cockroaches.)
Hmmm. I might argue that the same analogy applies to the strawman
(ie.overkill). Neither analogy gets us anywhere.


My aim is to avoid the horrific syntax that exception abstraction
requires. If someone can show a sensible approach at the syntax level
for function types and methods that need to be transparent, then I
have no objection to the basic direction of the strawman. I simply
don't believe such a syntax exists.

Also, I would re-emphasise, as others have, that if all exceptions in
Java were unchecked, then we would not be having this discussion. With
respect to both parties, has Oracle simply accepted Neal's definition
of "exception transparency" (ie "exception abstraction") without going
back to the original problem?

To summarise, this thread contrasts two options:
1) Strawman. Lots of extra syntax. Fully retains the power of checked
exceptions.
2) Lone throws. Little extra syntax. Reduces the use of checked exceptions.
Reinier has presented another approach which also has merit.

My sole goal in this project is to ensure that the end result is
usable by typical Java developers (a combination of semantics and
syntax). Variance mark 2 (both semantics and syntax) must be avoided
at all costs.


> Besides the points raised here, I could easily imagine a world where
> developers who don't like checked exception just decorated every method with
> "throws".  I don't know if that is the intent of the proposal or simply a
> side-effect, but it is (in our view) some pretty serious collateral damage.
It is not the intent of the author, no. (I do dislike checked
exceptions, but I fully acknowledge that many like them, and they are
a feature of Java).

If some people chose to make use of the feature, then that is their
decision. Given that the vast majority of existing open source
libraries current wrap checked in unchecked, I suspect it would be
very widely adopted. So, yes, choosing this proposal should be done
with a full awareness that it will be used to reduce the role of
checked exceptions generally. Some might view this as "serious
collateral damage" - others might view this as a "separate language
feature that has benefits in P.Lambda". The truth is somewhere in the
middle.

Finally, as many have commented - there is nothing new here. Escaped
checked exceptions already happen, and are very hard to catch today.
Given the increasing integration of languages other than Java
(something I believe was being actively supported by Sun/Oracle), the
escaped exception issue is only getting worse. Being honest about it
would be a service to the whole Java community separate to Lambda.

(Actually, a Project Coin feature to allow the coder to catch escaped
checked exceptions would have been a good submission on its own)

Plus, would "lone throws" not help some of the API parts of invoke
dynamic where methods might throw exceptions?

Occasionally its time to think the unthinkable ;-)

Stephen