Java InvocationTargetException 真因在 getCause 里

这个异常是「邮差」，不是「病因」。它本身几乎从不携带有用信息——getMessage() 常常是空，printStackTrace() 也只见 sun.reflect 那些代理栈帧。真正的业务异常（一个 NPE、一个 SQLException）被装进了它的 cause 里等着你去取。盯着 InvocationTargetException 本身排查，只会越查越偏。

Issue & Env（案发现场与环境）

现象：通过反射 Method.invoke()、动态代理、框架内部反射调用时抛异常，日志里只有一句 InvocationTargetException，看不到根因。
环境：Java 反射、JDK 动态代理、Spring AOP、MyBatis、Dubbo 泛化调用等场景。

StackTrace（堆栈日志）

外层只有反射的栈帧，没有业务信息：

java.lang.reflect.InvocationTargetException
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)

真正的异常在 getCause() 里，得主动挖出来，比如里面可能是：

Caused by: java.lang.IllegalArgumentException: DB connection timeout
    at com.stacktraces.demo.Sample.doWork(Sample.java:6)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at java.lang.reflect.Method.invoke(Method.java:498)
    ... 1 more

Reproduce（复现代码）

被反射调用的方法内部抛了个异常，invoke 把它包起来：

public class Sample {
    public void doWork() {
        throw new IllegalArgumentException("DB connection timeout");
    }
}

// 调用方
Method m = Sample.class.getMethod("doWork");
try {
    m.invoke(new Sample());
} catch (InvocationTargetException e) {
    System.out.println("直接打印：" + e); // 只看到 InvocationTargetException
    Throwable real = e.getCause();       // 这才是真正的异常
    System.out.println("真实原因：" + real);
}

只打印 e，你就是把病根丢进了黑洞。

Root Cause（根因分析）

InvocationTargetException 是 JVM 规范要求的包装器：它的职责是区分「反射调用本身失败」和「被调用方法内部失败」。当你通过 Method.invoke() 或 Constructor.newInstance() 调用目标方法时，目标方法抛出的任何异常，都会被 JVM 统一包成 InvocationTargetException 再抛出来。

原因很实在：这一层是通过字节码指令 invokevirtual 间接调用的，编译器没法像直接调用那样预先声明「这个方法可能抛哪些 checked 异常」，于是 JVM 干脆用 InvocationTargetException 通吃，把原始异常塞进 cause。

但它不重写 toString()，所以 e.getMessage() 和 System.out.println(e) 都不会自动展开 cause，多数日志框架默认也只打印一层，于是真实异常被淹没。Spring 的动态代理还会再包一层 UndeclaredThrowableException，形成「包装套包装」。

The Fix（解决方案）

核心动作只有一个：显式解包，拿到 cause 里的真异常。

try {
    method.invoke(target, args);
} catch (InvocationTargetException e) {
    Throwable root = e.getCause();          // 拿真实异常
    log.error("业务异常透传", root);         // 输出真实堆栈
    throw new RuntimeException(root);        // 或重新抛出
}

遇到多层包装（反射套动态代理），循环往下解：

public static Throwable unwrap(Throwable e) {
    while (e instanceof InvocationTargetException
            || e instanceof UndeclaredThrowableException) {
        Throwable cause = e.getCause();
        if (cause == null) break;
        e = cause;
    }
    return e;
}

JDK 文档也提示 getTargetException() 是历史遗留写法，用通用的 getCause() 更合适。日志上，确保你的框架递归展开嵌套异常（例如配置 %xEx 而不是只 %ex），否则线上排查时又得回到「真相藏起来」的老路。