I agree with Stuart.
David
On 19/04/2016 9:05 AM, Stuart Marks wrote:
On 4/17/16 10:31 AM, joe darcy wrote:
With talk of deprecation in the air [1], I thought it would be a fine
time to
"In the Spring a young man's fancy lightly turns to thoughts of
deprecation."
-- apologies to Tennyson
examine one of the bugs on my list
JDK-6850612: Deprecate Class.newInstance since it violates the
checked
exception language contract
As the title of the bug implies, The Class.newInstance method
knowingly violates
the checking exception contract. This has long been documented in its
specification: [...]
Comments on the bug have suggested that besides deprecating the
method, a new
method on Class could be introduced,
newInstanceWithProperExceptionBehavior,
that had the same signature but wrapped exceptions thrown by the
constructor
call in the same way Constructor.newInstance does.
Deprecating Class.newInstance() seems reasonable to me, for the reasons
you've stated.
It's not clear to me that a replacement method adds much value. I
believe it's possible to replace a call
clazz.newInstance() // 1
with the call
clazz.getConstructor().newInstance() // 2
which is only a bit longer. Both snippets are declared to throw
InstantiationException and IllegalAccessException. But snippet 2 also is
declared to throw InvocationTargetException and NoSuchMethodException.
This would seem to be an inconvenience, but *all* of these exceptions
are subtypes of ReflectiveOperationException. It seems pretty likely to
me that most code handles these different exception types the same way.
So it's fairly low cost to replace snippet 1 with snippet 2, and to
adjust the exception handling to deal with ReflectiveOperationException.
Thus I don't see much value in adding a new method such as
Class.newInstanceWithProperExceptionBehavior().
s'marks
