RE: java.lang.Class patches

[Jeroen Frijters]

Archie Cobbs wrote:
> Jeroen Frijters wrote:
> > > Could you fix this so that the exception is declared and 
> then maybe 
> > > we don't need that native method in VMClass to throw the 
> exception?
> > 
> > No, the problem is that *any* exception can be thrown from a 
> > constructor (and hence from Class.newInstance()). Yet, 
> > Class.newInstance() doesn't declare "throws Exception" and it can't 
> > because that would break existing code (wouldn't compile anymore).
> 
> Dumb question.. why can't Sun just have Class.newInstance() 
> throw an InstantiationException, with the original exception 
> chained to the InstantiationException using initCause(), if 
> the constructor throws a random exception? The API docs 
> actually imply this, saying that an InstantiationException is 
> thrown "if the instantiation fails for some other reason".
> 
> Seems like this would be the best way to fix this bug while 
> still being backwards compatible.

There might be code out there that does this:

class Foo {
  public Foo() throws IOException { ... }
}

class Bar {
  void method() {
     try {
        // we need to catch IOException, but the compiler
        // won't let us without this if
        if(false) throw IOException();
        factory.newInstance();
     } catch(IOException x) {
        //...
     }
  }
}

Changing newInstance() to wrap the exception would break this code.

If more people disagree with me, we could change Class.newInstance to
wrap the exception if VMClass.throwException returns. That way the VM
implementor can choose which of the two behaviors they want.

Regards,
Jeroen