Points about language support for 292

[Rémi Forax]

Joe Darcy a écrit :
> On 05/01/09 12:38 PM, Alex Buckley wrote:
>   
>> John Rose wrote:
>>   
>>     
>>> 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!
>>>     
>>>       
>> I'm really after a mandatory catch(Exception) block for any try block 
>> that contains InvokeDynamic. An ignored checked exception is THAT 
>> dangerous. If the programmer catches more specific checked exceptions 
>> first, that's great. If the programmer wraps Exception in 
>> RuntimeException always, or some of the time, or never, that's great 
>> too, but let them document it locally.
>>
>>   
>>     
>
> 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