Points about language support for 292
Alex.Buckley at Sun.COM
Thu Apr 30 15:15:08 PDT 2009
1.1: "The complete lack of supertypes makes it an unusual type, on a par
But InvokeDynamic is defined as a class with a superclass of Object a
few lines earlier. The text in () looks redundant.
1.5: As the JVM executes, checked exceptions may be produced by any
Please don't put "JVM" and "checked exceptions" in the same sentence!
More importantly, I don't agree with "the possibility of a missed catch
of a checked exception is not considered to be a hazard." An exception
handler further up the stack that catches unchecked exceptions will miss
it, and the program will in all likelihood stop.
In other words, this is a relaxation too far of static exception
checking. One option is to have InvokeDynamic.foo() claim to throw all
possible checked exceptions. If one actually leaks back to the call site
from a dynamic language's runtime, it should be caught right there.
Another option, and perhaps a better one since it partitions
InvokeDynamic off from checked exceptions entirely, is to specify that
its infinite static methods can throw only unchecked exceptions (or one
in particular, if you like). An implementation would have to wrap
Neal: InvokeDynamic IS now a reference type. Regarding <..> to indicate
return type for a dynamic call site, how does C# denote that?
More information about the coin-dev