Re: java.lang.Class patches

[Brian Jones]

"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.

Brian
-- 
Brian Jones <address@hidden>