Points about language support for 292

Alex Buckley Alex.Buckley at Sun.COM
Thu Apr 30 15:15:08 PDT 2009

Hi John,

1.1: "The complete lack of supertypes makes it an unusual type, on a par 
with Object."

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 
invokedynamic call.

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 
checked exceptions.

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 mailing list