Points about language support for 292

[Derek Foster]

-----Original Message-----
>From: Rémi Forax <forax at univ-mlv.fr>
>Sent: May 1, 2009 4:46 PM
>To: Joe Darcy <Joe.Darcy at Sun.COM>
>Cc: Alex Buckley <Alex.Buckley at Sun.COM>, John Rose <John.Rose at Sun.COM>, coin-dev at openjdk.java.net
>Subject: Re: Points about language support for 292
>
>Joe Darcy a écrit :
>> Yes, for better or worse the Java source language includes checked 
>> exceptions and InvokeDynamic call sites should not be exempt from 
>> participating in that rule.
>>
>> (The existing holes/bugs in this area, like Constructor.newInstance 
>> should not be expanded.)
>>
>> -Joe
>>   
>
>I don't agree.
>You can already fool the compiler, by example,
>using generics. In that case, the compiler emit an unsafe cast warning.
>
>public class ExceptionTest {
>  interface I<E extends Exception> {
>    void m() throws E;
>  }
>  static class A implements I<IOException> {
>    public void m() throws IOException {
>      new FileInputStream("hello");
>   }
>  }
>  public static void main(String[] args) {
>    I<RuntimeException> i=(I)new A();
>    i.m();
>  }
>}
>
>Why not raise a warning saying that InvokeDynamic creates a hole because
>exceptions are not managed ?
>
>Rémi

Why not do what's done in other similar circumstances (e.g. Method.invoke()), and have a method called via InvokeDynamic be implicitly declared with a "throws InvocationTargetException" throws specifier, with any exceptions it throws wrapped in an InvocationTargetException instance? That way, the caller will be forced to add a catch clause for InvocationTargetException, but there will be no chance of confusing an exception due to failure to call the method (NoSuchMethodException, etc.) with an exception thrown by the body of the method itself.

Derek