Points about language support for 292
John Rose
John.Rose at Sun.COM
Fri Jun 12 22:42:33 PDT 2009
Back to (the ever-contentious topic of) checked exceptions, w.r.t. JSR
292.
Although I doubted at first, I now agree (with Alex, Neal, et al) that
where JSR 292 punches into the JLS, it should not bring a new loophole
in the static checking of throws and catches.
I have converted the mlvm patches for javac and the JSR 292 runtime,
and found in almost all cases that I had to put an annoying "throws
Throwable" on various MethodHandles APIs and intermediate shim
methods. Once done, it looks unappetizing, but so far the extra
"throws" do not seem to impede using Java as a systems programming
language for dynamic language implementations.
(Also, some of you will like this news, I think the exercise turned up
one potential bug, where checked exceptions from the bootstrap method
would have mingled with the call site if not caught and wrapped
properly; this would have been very confusing.)
So I think the "look" of dynamic language implementation code in Java
will include a fair number of "throws Throwable" to mollify Java's
exception checking rules. Yet to be seen is what effect such blanket
throwing will have on surrounding code. I am starting to reach for
remedies like this:
void foo() throws IOException {
doSomeIO();
try {
InvokeDynamic.foo();
} catch (Throwable ex) {
throw checkedException(ex, IOException.class);
}
doSomeMoreIO();
}
where, more or less:
static <T extends Throwable> T checkedException(Throwable t,
Class<T> tc) throws Error, RuntimeException {
if (tc.isInstance(t)) return tc.cast(t);
if (t instanceof Error) throw (Error) t;
if (t instanceof RuntimeException) throw (RuntimeException) t;
throw InternalError("undeclared checked exception", t);
}
This guy should be in the JDK, in case the set of unchecked throwables
grows (e.g., to include non-local jump types).
-- John
P.S. Here's a good Java puzzler: Without using any non-standard
language features, figure out how to generalize checkedException to
two or more variable throws types.
On May 2, 2009, at 6:00 PM, Paul Benedict wrote:
>>> Sorry, wrapping checked exceptions is a non-starter for 292.
>>> Wrapping
>>> of all sorts is one of the reasons reflection is unusably slow for
>>> dynamic language implementation.
>
> Good point. But I think it is a bad idea to alter the JLS to catch
> undeclared checked exceptions -- if that is really being considered.
>
> Neal appears to be correct in requiring that a dynamic call site
> throws Throwable. Dynamic languages can ingnore the exceptions if they
> want, but the Java code shouldn't.
>
> -- Paul
>
More information about the coin-dev
mailing list