Points about language support for 292

[Neal Gafter]

On Fri, May 1, 2009 at 12:06 PM, John Rose <John.Rose at sun.com> wrote:

> Dynamic languages rely on programmer foresight (that estimable
> faculty) to put the right catches around potentially throwing code.
> So must the loophole into Java.


That would be fine if the problem (an uncaught and undeclared checked
exception) had no way to leak into otherwise statically typed code, but this
proposal does allow such leaks.  Java's invariants should be preserved
outside of and around (but not necessarily inside) dynamic code.


> The design as it stands lets the exceptions flow out of the call site,
> without attempting to document them there.  It allows the programmer
> to write catches for the relevant ones, and assumes that the
> programmer will write all the necessary ones, without help from static
> exception checking:
>
> try { InvokeDynamic.<void>foo(bar, baz); }
> } catch (IOException x) { /* programmer-written logic here*/ }
> } catch (AnotherBadException x) { /* more logic here*/ }
>
> That's status quo for dynamic languages!


Java isn't a dynamic language.  It is not legal to put catch (IOException
ex) on a try block that can't throw that checked exception (in the JLS
sense), so further language changes would be required to allow this.  Your
spec says "Therefore, it is valid both to catch and not to catch checked
exceptions at any dynamic call site."  That is not precise enough; you'd
need a complete overhaul of JLS section
11.2<http://java.sun.com/docs/books/jls/third_edition/html/exceptions.html#11.2>at
the very least, and I suspect the required changes would be quite
messy.
I think it's better to just say that a dynamic call site throws Throwable
(just saying that it throws Exception isn't enough).