Exception transparency - lone throws (no checked exceptions)

[Daniel Yokomizo]

On Sun, Jun 13, 2010 at 8:47 AM, Stephen Colebourne
<scolebourne at joda.org> wrote:
> On 13 June 2010 04:18, Daniel Yokomizo <daniel.yokomizo at gmail.com> wrote:
>> 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.
> +1
>
>> 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.
> You call it clear. I call it unreadable. Different kinds of "clear".
>
> ie. It is clear from a type-information basis. It is not clear to
> anyone glancing at a method in code or Javadoc and trying to figure
> out what the heck it does. By way of comparison, pre Java 5 we would
> have:
>
>  interface ExecutorService {
>    Future invoke(Callable c);
>  }
>
> which is /instantly/ readable.

This is mostly a matter of familiarity. If people don't know how to
read generic declarations they'll obviously fail to understand them.
Also it's obvious that generics require more effort to understand than
no generics, OTOH they provide a better foundation to write correct
code.

OTOH just by glancing the pre-java5 declaration I would have no idea
which kind of exceptions could/would be thrown. Ditto for what kind of
results.

[From your other message]
> It you want a closure that declares checked exceptions,
> simply define a SAM for it.

That is not possible without some form of exception abstraction.
Currently the only way to write a compose a function types aware of
exceptions (F) is to use an exception supertype:

<E,F,G, Z extends Throwable, X extends Z, Y extends Z> F<E,G,Z>
compose(F<E,F,X> ef, F<F,G,Y> fg);

But the most specific type could be:

<E,F,G, throws X, throws Y> F<E,G,throws X | Y> compose(F<E,F, throws
X> ef, F<F,G,throws Y> fg);

I'm not arguing about the clarity of this syntax. The issue is how can
we work generically with checked exceptions.

> I'm simply posing the question "at what point does adding
> type-information impair readability to the point of being
> unacceptable?". I don't get to choose the answer - Oracle does.
>
> Stephen

Best regards,
Daniel Yokomizo