Exception transparency - lone throws (no checked exceptions)

[Stephen Colebourne]

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.

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