Exception transparency - lone throws (no checked exceptions)

[Daniel Yokomizo]

On Sat, Jun 12, 2010 at 9:02 PM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> 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?

In a similar note if Java supported both dynamic and static typing
from the beginning a similar discussion would have occurred about
generics :)

> 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.

AFAICS there are at least three distinct goals/use cases being conflated:

1. A way to reduce syntax boilerplate when it's necessary to propagate
exceptions from a closure body (or any other method body).
2. A way to express that a certain set of checked exceptions may be
thrown by a function type.
3. A way to manipulate/compose throws clauses in a generic-like manner.

Despite personal preferences, we can agree that not all proposals
cover all goals. Also, some of these use cases may be more critical
than others.

The empty throws proposal covers just goal 1 and doesn't help if we
are writing generic code (because this is covered also by goals 2 & 3)
we end up having to declare everything with throws (e.g. a compose
would have to declare empty throws).

> 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.

Variance is part of the cost of higher order types with subtyping. The
particular solution adopted in Java is problematic, not variance. We
could avoid the variance woes by dropping static typing, but it would
create a less (statically) expressive solution.

Similarly the three goals exist, if we reduce the scope to the first
goal only we can have a simpler solution, but it'll be a partial
solution.

>> 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.

I suspect most libraries wrap exceptions (either in unchecked or
another checked) because Java didn't have a way to express
abstractions/parametrization over exceptions. For example, the
contract between Callable, Future and ExecutorService could be much
better expressed without something like ExecutionException if we had
support for goals 2 & 3.

Actually with abstraction/parametrization over exceptions it wouldn't
be necessary to create so many intermediate exceptions and generic
code could be written with better contracts. Using the Future example
we could have:

interface ExecutorService<throws X> {
    <E, throws Y> Future<E, throws X | Y> invoke(Callable<E, Y> c);
}

The signature makes clear which kind of exceptions are possible,
problems from the Callable and problems from the Executor.

> 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 ;-)

Like deprecating support for unchecked exceptions and adding exception
abstraction/parametrization at the correct places :)

> Stephen

Best regards,
Daniel Yokomizo.