Closure conversion vs silly type parameter
Mark Mahieu
mark at twistedbanana.demon.co.uk
Tue May 13 19:37:44 PDT 2008
This one has me scratching my head a bit. The following (rather odd)
class compiles successfully despite there being a checked exception
thrown which is never caught or declared to be thrown in the method
signatures:
public class Hmmm {
public static void main(String[] args) {
foo() {
throw new Exception();
}
}
static <T extends {==> void}> void foo(T block) {
block.invoke();
}
}
Interestingly, the following version, which assigns the closure
literal to a variable of the corresponding function type first, fails
to compile (which is as I'd expect).
public class Hmmm2 {
public static void main(String[] args) {
{ => void throws Exception} f = {=> throw new Exception(); };
foo(f);
}
static <T extends {==> void}> void foo(T block) {
block.invoke();
}
}
Reading the closure conversion and function type subtyping rules
again, I can't see why one would be allowed and the other not... any
clues as to what I'm missing here?
Mark
More information about the closures-dev
mailing list