What could cause java.lang.reflect.InvocationTargetException?

JavaExceptionReflectionInvoke

Java Problem Overview


Well, I've tried to understand and read what could cause it but I just can't get it:

I have this somewhere in my code:

 try{
 ..
 m.invoke(testObject);
 ..
 } catch(AssertionError e){
 ...
 } catch(Exception e){
 ..
 }

Thing is that, when it tries to invoke some method it throws InvocationTargetException instead of some other expected exception (specifically ArrayIndexOutOfBoundsException). As I actually know what method is invoked I went straight to this method code and added a try-catch block for the line that suppose to throw ArrayIndexOutOfBoundsException and it really threw ArrayIndexOutOfBoundsException as expected. Yet when going up it somehow changes to InvocationTargetException and in the code above catch(Exception e) e is InvocationTargetException and not ArrayIndexOutOfBoundsException as expected.

What could cause such a behavior or how can I check such a thing?

Java Solutions


Solution 1 - Java

You've added an extra level of abstraction by calling the method with reflection. The reflection layer wraps any exception in an InvocationTargetException, which lets you tell the difference between an exception actually caused by a failure in the reflection call (maybe your argument list wasn't valid, for example) and a failure within the method called.

Just unwrap the cause within the InvocationTargetException and you'll get to the original one.

Solution 2 - Java

The exception is thrown if

> InvocationTargetException - if the underlying method throws an exception.

So if the method, that has been invoked with reflection API, throws an exception (runtime exception for example), the reflection API will wrap the exception into an InvocationTargetException.

Solution 3 - Java

Use the getCause() method on the InvocationTargetException to retrieve the original exception.

Solution 4 - Java

From the Javadoc of Method.invoke()

> Throws: InvocationTargetException - if the underlying method throws an exception.

This exception is thrown if the method called threw an exception.

Solution 5 - Java

This will print the exact line of code in the specific method, which when invoked, raised the exception:

try {

    // try code
    ..
    m.invoke(testObject);
    ..

} catch (InvocationTargetException e) {

    // Answer:
    e.getCause().printStackTrace();
} catch (Exception e) {

    // generic exception handling
    e.printStackTrace();
}

Solution 6 - Java

That InvocationTargetException is probably wrapping up your ArrayIndexOutOfBoundsException. There is no telling upfront when using reflection what that method can throw -- so rather than using a throws Exception approach, all the exceptions are being caught and wrapped up in InvocationTargetException.

Solution 7 - Java

This describes something like,

> InvocationTargetException is a checked exception that wraps an > exception thrown by an invoked method or constructor. 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."

Solution 8 - Java

You can compare with the original exception Class using getCause() method like this :

try{
  ...
} catch(Exception e){
   if(e.getCause().getClass().equals(AssertionError.class)){
      // handle your exception  1
   } else {
      // handle the rest of the world exception 
   }
} 

Solution 9 - Java

I had a java.lang.reflect.InvocationTargetException error from a statement calling a logger object in an external class inside a try / catch block in my class.

Stepping through the code in the Eclipse debugger & hovering the mouse over the logger statement I saw the logger object was null (some external constants needed to be instantiated at the very top of my class).

Solution 10 - Java

A problem can also be that the targetSdkVersion is upped and that you use deprecated Gradle manifest features. Try lowering the targetSdkVersion again and see if it works. In my case it was targetSdkVersion 31 -> 30

Solution 11 - Java

This exception is thrown if the underlying method(method called using Reflection) throws an exception.

So if the method, that has been invoked by reflection API, throws an exception (as for example runtime exception), the reflection API will wrap the exception into an InvocationTargetException.

Solution 12 - Java

I was facing the same problem. I used e.getCause().getCause() then I found that it was because of wrong parameters I was passing. There was nullPointerException in fetching the value of one of the parameters. Hope this will help you.

Solution 13 - Java

Invocation Target Exception:

> I strongly believe that any naming convention has diligent thoughts invested > in it. And, it is more than likely that our questions have their > answers in the names, if we tried finding a rationale behind the name.

Let's break the name up into 3 parts. "Exception" has occurred when "Invoking" a "Target" method. And, the exception is thrown with this wrapper when, a method is invoked via reflection in Java. While executing the method, there could be any type of exception raised. It is by design, that the actual cause of the exception is abstracted away, to let the end user know that the exception was one that occurred during a reflection based method access. In order to get the actual cause, it is recommended that the exception is caught and ex.getCause() is called. Best practice is to, in fact throw the cause from the catch block that caught the InvocationTargetException

try{
    method.invoke();
} catch(InvocationTargetException ite) {
    throw ite.getCause();
} catch(Exception e) {
    // handle non-reflection originated exceptions
    throw e;
}

I know it is similar to the other answers, but I wanted to make it more clear about "when" this exception type is generated by Java, so that it is a mystery to none.

Solution 14 - Java

  1. List all jar files from the Eclipse Navigator mode
  2. Verify that all the jar files are in binary mode

Solution 15 - Java

The error vanished after I did Clean->Run xDoclet->Run xPackaging.

In my workspace, in ecllipse.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionuser550413View Question on Stackoverflow
Solution 1 - JavaJon SkeetView Answer on Stackoverflow
Solution 2 - JavaAndreas DolkView Answer on Stackoverflow
Solution 3 - JavaDaniel WardView Answer on Stackoverflow
Solution 4 - JavaPeter LawreyView Answer on Stackoverflow
Solution 5 - JavaRocky IndeView Answer on Stackoverflow
Solution 6 - JavaLivView Answer on Stackoverflow
Solution 7 - JavaSazzad Hissain KhanView Answer on Stackoverflow
Solution 8 - JavaMehdiView Answer on Stackoverflow
Solution 9 - JavaStuart CardallView Answer on Stackoverflow
Solution 10 - JavajobbertView Answer on Stackoverflow
Solution 11 - JavaNikhil KumarView Answer on Stackoverflow
Solution 12 - JavaDeepak VajpayeeView Answer on Stackoverflow
Solution 13 - JavaAbhay NagarajView Answer on Stackoverflow
Solution 14 - JavaManikView Answer on Stackoverflow
Solution 15 - JavaAshutosh AnandView Answer on Stackoverflow