嗯,我试着去理解和解读导致它的原因,但我就是不明白:

在我的代码中有这样的代码:

 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.

是什么导致了这样的行为或者我如何检查这样的事情?


来自Method.invoke()的Javadoc

如果底层方法抛出异常,则抛出:InvocationTargetException。

如果调用的方法抛出异常,则抛出此异常。


通过调用带有反射的方法,您增加了一个额外的抽象级别。反射层将任何异常包装在InvocationTargetException中,这使您可以区分实际由反射调用中的失败(例如,可能您的参数列表无效)引起的异常和所调用的方法中的失败。

只需在InvocationTargetException中展开原因,就会得到原始的原因。


则抛出异常

InvocationTargetException—如果底层方法抛出异常。

因此,如果用反射API调用的方法抛出异常(例如运行时异常),反射API将把异常包装到InvocationTargetException中。


那个InvocationTargetException可能正在封装你的ArrayIndexOutOfBoundsException。在使用反射时,没有预先说明该方法可以抛出什么——因此,与使用抛出异常方法不同,所有异常都被捕获并封装在InvocationTargetException中。


使用InvocationTargetException上的getCause()方法检索原始异常。


列出Eclipse Navigator模式下的所有jar文件 验证所有jar文件都是二进制模式


它描述的是,

InvocationTargetException是包装对象的受控异常 由被调用的方法或构造函数引发的异常。截至发布 1.4,此异常已进行了改进,以符合通用异常链接机制。即“目标异常” 在施工时提供,并通过 getTargetException()方法现在被认为是原因,并且可能是 可以通过Throwable.getCause()方法访问 前面提到的“遗留方法”。


如果底层方法(使用Reflection调用的方法)抛出异常,则抛出此异常。

因此,如果反射API调用的方法抛出异常(例如运行时异常),反射API将把异常包装到InvocationTargetException中。


这将打印特定方法中的精确代码行,当调用该方法时,会引发异常:

try {

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

} catch (InvocationTargetException e) {

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

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

我这么做之后,错误就消失了 Clean->执行xDoclet->执行xPackaging。

在我的工作空间,在月蚀中。


您可以使用getCause()方法与原始异常类进行比较,如下所示:

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

我也面临着同样的问题。我使用e.getCause(). getcause(),然后我发现这是因为我传递了错误的参数。在获取其中一个参数的值时出现nullPointerException。 希望这对你有所帮助。


我有一个java.lang.reflect.InvocationTargetException错误,来自在我的类的try / catch块内部的外部类中调用记录器对象的语句。

在Eclipse调试器中遍历代码并将鼠标悬停在记录器语句上,我看到记录器对象为空(一些外部常数需要在类的最顶部实例化)。


问题还可能是targetSdkVersion升级了,并且您使用了已弃用的Gradle清单特性。尝试再次降低targetSdkVersion,看看它是否有效。在我的例子中,它是targetSdkVersion 31 -> 30


调用目标异常:

我坚信,任何命名惯例都有勤奋的思想投入 在里面。而且,很有可能我们的问题都有他们的问题 答案就在名字里,如果我们试着找出名字背后的原因。

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;
}

我知道它与其他答案类似,但我想更清楚地说明Java生成这种异常类型的“何时”,因此它对任何人来说都是一个谜。