Why a new type parameter for exception transparency?

[Paul Benedict]

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