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），否則線上排查時又得回到「真相藏起來」的老路。