Exception transparency - lone throws (no checked exceptions)

[Stephen Colebourne]

On 10 June 2010 17:04, Alex Blewitt <alex.blewitt at gmail.com> wrote:
> How could this work in the face of subclasing? What if there's an interface
> or abstract method with a lone throws? What if there are two implementers
> which throw different (distinct) exceptions? What if I invoke that abstract
> method - what types am I expecting to catch?

If the abstract method has "lone throws", then any caller is permitted
to catch any exception, checked or not. Whether one is thrown is
entirely up to the implementation of the abstract method.

This is no different to today, where two implementations of the same
abstract method can throw two different runtime exceptions.

I should note that an overriding method cannot specify lone throws
unless the superclass definition also specifies lone throws.

> I also don't see how this works in the transitive closure case, with a
> calling b and b calling c (different files) and c throws IOException. At
> (first) compile time, the lone throws of a and b will have IOException added
> to the list.
> If you then change c to throw a new set of exceptions (say, adding
> java.sql.SQLException) then the throws of b and a need to be updated. With
> the line throws, the complier will have to compile potentially every call
> path to that point again.

I'm proposing that the lone throws of c simply permits it to throw any
exception and effectively have them become unchecked (with the
side-effect that any immediate caller of a method declared with lone
throws can catch checked exceptions that previously it couldn't).

The IOException in your example is not added to the method signature
of c. Therefore, adding SQLException also makes no difference to
callers, hence no re-compilation.

Stephen