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