RE: java.lang.Class patches

[Jeroen Frijters]

Brian Jones wrote:
> "Jeroen Frijters" <address@hidden> writes:
> 
> > > 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.
> 
> It should be okay to wrap the exception in this case as the 
> developer can only really rely upon documented throws 
> information.  Everything else is subject to change without 
> any notice with each JDK release.

If factory is known to be a Foo class (or subclass), the caller knows
that the constructor might throw an IOException (after all it declares
it), so newInstance() can also throw an IOException.

Anyway, I hope you agree that having an empty VMClass.throwException
won't hurt anyone. That way VM implementors can choose to be compatible
with Sun or implement the spec.

Regards,
Jeroen