Why a new type parameter for exception transparency?

[Neal Gafter]

Paul-

The short answer is that a different generic type inference mechanism must
be used on these exception parameters than on ordinary type parameters.  For
example, if you invoke this method on a closure that throws IOException and
SQLException, the ordinary generic type inference mechanism will conclude
that E is the type Exception.  As a consequence, the caller will have to
catch Exception rather than just IOException and SQLException.  The approach
I've taken to address that is to add a modifier on the type parameter that
directs the inference mechanism to infer disjunction types rather than lub()
types.  Perhaps another approach would be to just take the hint from the
fact that the type parameter's bound is a checked exception type.  That is
not strictly backward source-compatible, but it might be compatible enough
to allow us to simplify the syntax as you suggest.

Cheers,
Neal

On Wed, Nov 18, 2009 at 8:02 PM, Paul Benedict <pbenedict at apache.org> wrote:

> After reading the 0.6 version of the spec, I do not understand why a
> new type parameter must be created to support exception transparency.
> My understanding of closures is definitely in the amatuer range;
> perhaps someone can enlighten me why this code block:
>
> public static <T, throws E extends Exception>
> T withLock(Lock lock, #T() throws E block) throws E {
>    lock.lock();
>    try {
>        return block.invoke();
>    } finally {
>        lock.unlock();
>    }
> }
>
> is not better written (and better understandable) as:
>
> public static <T, E extends Exception>
> T withLock(Lock lock, #T() throws E block) throws E {
>    lock.lock();
>    try {
>        return block.invoke();
>    } finally {
>        lock.unlock();
>    }
> }
>
> The keyword "throws" looks sorely out of the place, but truly aside
> from the aesthetics, I can't find a reason for it's necessity. The
> "throws E extends Exception" is also nearly duplicated with "#T()
> throws E" -- we already know it throws something, so it doesn't need
> two "throws". Can't one be sacrificed?
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/closures-dev/attachments/20091118/dec4fa47/attachment.html