[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

java.lang.Class.newinstance(): exceptions; desired behavior?

From: Steven Augart
Subject: java.lang.Class.newinstance(): exceptions; desired behavior?
Date: Thu, 23 Sep 2004 12:25:39 -0400

I think our implementation of java.lang.Class's newinstance() is
incorrect.  Specifically, Class.newinstance() uses reflection to
invoke a class's zero-argument constructor and then, if it catches an
InvocationTargetException, unwraps that exception, throwing whatever
exception was originally thrown by the constructor.

The exact code we currently have is:

    catch (InvocationTargetException e)
        throw (InternalError) new InternalError
          ("VMClass.throwException returned").initCause(e);

This has the effect that Class.newinstance() can throw any exception
at all, without any warning to the caller.  

* This is at variance with the (different) interpretation specified
in the Javadoc comment at the head of Class.newInstance(): 

   * @throws InstantiationException if there is not a no-arg constructor
   *         for this class, including interfaces, abstract classes, arrays,
   *         primitive types, and void; or if an exception occurred during
   *         the constructor

The patch itself is trivial, but I want to check that others share my
interpretation; this seems so wrong that I wonder whether I'm missing
something.  I would change the code to read something like:

    catch (InvocationTargetException e)
        Throwable t = e.getTargetException();
        InstantiationException ie 
           = new InstantiationException("Trouble calling newinstance()"
                 + " on the class " + toString());
        throw ie;

One effect of this mis-implementation is the existence of a
VM-specific method that does not need to exist:
VMClass.throwException(Throwable).  Its stub reads:

   * Throw a checked exception without declaring it.
  static native void throwException(Throwable t);

This method is only used by our java.lang.Class.newInstance().

This method can go away in future releases of Classpath.  In the mean
time, I have been implementing VMClass for Jikes RVM, so that we can
stop using our own version of java.lang.Class.  Until the next
release of Classpath eliminates the need for VMClass.throwException(),
it seems to me that the best solution is to make
VMClass.throwException() wrap the exception it's given with an
InstantiationException and throw that.

I am looking for feedback on this, especially including any alternative
interpretations of how Class.newInstance() should handle it if the
target class's zero-arg constructor throws an exception.


--Steve Augart

Steven Augart

Jikes RVM, a free, open source, Virtual Machine:

reply via email to

[Prev in Thread] Current Thread [Next in Thread]