Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

When is InvocationTargetException.getCause() null?

As per the javadocs, InvocationTargetException.getCause() can be null:

Returns the cause of this exception (the thrown target exception, which may be null).

But the documentation also says that it wraps an existing exception:

InvocationTargetException is a checked exception that wraps an exception thrown by an invoked method or constructor.

So it seems to me that InvocationTargetException.getCause() can never be null.

Am I missing something?

UPDATE

Yes, I missed something -- the default constructor of InvocationTargetException would cause getCause() to be null.

The question I have now is why provide a default constructor for this class at all. Is there a usecase where the exception needs to be thrown with a null cause?

like image 530
Miserable Variable Avatar asked Jul 16 '13 18:07

Miserable Variable


People also ask

How do I fix InvocationTargetException in Java?

Since the InvocationTargetException is caused by another exception thrown by the invoked method, the underlying exception can be found using the getCause() method. Therefore, resolving the InvocationTargetException error equates to finding the actual exception and resolving it.

How do I get actual exception from InvocationTargetException?

The InvocationTargetException is caused by the invoked method, which throws an exception. The underlying exception can be found using the getCause() method.

What is the cause of InvocationTargetException in Java?

The InvocationTargetException occurs mainly when working with the Java reflection API to invoke a method or constructor, which throws an exception.


2 Answers

So.

@xtravar's comment on my (much) earlier answer has caused be to have another look at this issue. And I might just got it. Please bear with me.

InvocationTargetException was introduced to Java very early. At least as early as some JDK 1.1.X which dates back to anywhere between February 1997 to December 1998. How do I know it's that old? After all, there's no @since 1.1 mark on the class.
I happened to see the following javadoc on the serialVersionUID field:

/**
 * Use serialVersionUID from JDK 1.1.X for interoperability
 */

Right. So what?
So, according to docs of Throwable.getCause(), which InvocationTargetException eventually inherits:

While it is typically unnecessary to override this method, a subclass can
override it to return a cause set by some other means. This is appropriate
for a "legacy chained throwable" that predates the addition of chained
exceptions to Throwable.
...
@since 1.4

Now, please combine this with the following note on InvocationTargetException class docs:

As of release 1.4, this exception has been retrofitted to conform to
the general purpose exception-chaining mechanism.  The "target exception"
that is provided at construction time and accessed via the
getTargetException() method is now known as the cause,
and may be accessed via the Throwable.getCause() method,
as well as the aforementioned "legacy method."

See where I'm getting at?
The note on Throwable.getCause() is aimed exactly at InvocationTargetException (for the least). InvocationTargetExcpetion was used to chain exceptions before exception-chaining was introduced to Throwable...

And when InvocationTargetException was retrofitted, as noted, I assume that the language designers wanted to:

  1. prevent the possibility of InvocationTargetException having two different "causes" - one stored in target and the other in cause; and still
  2. be backward-compatible with existing code that relies on the target field.

That's why they left the target field as the one that's really used and implemented any existing constructors so that the cause field remains null for good. The implementation of getCause() for InvocationTargetException, of course, returns target as the cause.

So to answer

Is there a usecase where the exception needs to be thrown with a null cause?

Not really, it's not how the class is - and was - intended to be used.

And yet, this question remains:

why provide a default constructor for this class at all

(and this constructor seems to exist ever since)

I tend to think that this class is actually quite null-tolerant. After all, the public constructors permit null as the Throwable target. As a designer, if you already permitted that, you may as well add the protected default constructor that explicitly assigns null to target, enabling inheriting classes to construct the class however needed.

This also answers the original question:

So it seems to me that InvocationTargetException.getCause() can never be null.

Am I missing something?

Yes. InvocationTargetException is indeed intended to have a non-null target and cause. However, what's "missed" here is that target (and hence cause) unfortunately can be null, as nothing in the class forces it otherwise.

like image 76
yair Avatar answered Sep 22 '22 15:09

yair


InvocationTargetException extends ReflectiveOperationException which states

Common superclass of exceptions thrown by reflective operations in core reflection.

When you use reflection to call a method (or constructor).

Method method = ...
method.invoke(instance, ...);

If the method threw an exception, it would be stored in the target field of InvocationTargetException. That'll happen in most reflection cases.

The fact that there is an empty constructor leads me to believe it might be used differently in other cases.

JDK 7

private Throwable target;

/**
 * Constructs an {@code InvocationTargetException} with
 * {@code null} as the target exception.
 */
protected InvocationTargetException() {
    super((Throwable)null);  // Disallow initCause
}
like image 36
Sotirios Delimanolis Avatar answered Sep 18 '22 15:09

Sotirios Delimanolis