Why a new type parameter for exception transparency?
Paul Benedict
pbenedict at apache.org
Wed Nov 18 20:02:59 PST 2009
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
More information about the closures-dev
mailing list