undeclaredthrowableexception 是 jdk 动态代理为解决接口方法未声明却抛出受检异常而设计的包装机制：当 invocationhandler.invoke() 内部通过 method.invoke() 触发未在接口 throws 子句中声明的受检异常（如 ioexception）时，jvm 字节码层面禁止该异常直接抛出（因代理方法 exceptions 表为空），故强制将其封装为 runtimeexception 子类 undeclaredthrowableexception 并抛出；该异常自 jdk 1.4 起支持标准异常链，可通过 getcause() 或 getundeclaredthrowable() 获取原始异常。
为什么代理方法抛出受检异常会触发包装
Java 动态代理生成的代理类（如 $Proxy0）在调用被代理方法时，底层实际执行的是 InvocationHandler.invoke()。而该方法签名声明为 throws Throwable，看似能抛出任意异常——但代理类本身对每个接口方法的实现，**必须严格遵循接口方法的 throws 声明**。
当真实目标方法（例如 void doSomething() throws IOException）抛出一个受检异常（如 IOException），而该异常类型未出现在接口方法的 throws 子句中时，JVM 在生成代理字节码阶段就已限制：不能直接向外抛出这个未声明的受检异常。它必须被“合法转义”——于是将原始异常包裹进 UndeclaredThrowableException，再作为运行时异常向上抛出。
底层字节码层面的关键约束
代理类不是简单转发调用，而是由 ProxyGenerator 生成的、符合 JVM 字节码规范的 class 文件。JVM 要求：方法调用指令（如 invokevirtual）抛出的受检异常，必须在其方法描述符的 exceptions 表中显式列出。
由于代理类方法的签名完全继承自接口（例如 void doSomething()，无 throws），其字节码中 exceptions 表为空。此时若内部通过 method.invoke() 触发了 IOException，JVM 拒绝让该受检异常穿透出去，强制由代理逻辑捕获并封装为 UndeclaredThrowableException（它是 RuntimeException 子类，无需声明即可抛出）。
异常链如何构建与还原
UndeclaredThrowableException 的构造本质是异常链的初始化：
- 它在创建时，把原始受检异常（如
IOException）作为 cause 传入； - 从 JDK 1.4 起，它完全兼容标准异常链机制：
getCause()返回原始异常，getUndeclaredThrowable()是遗留方法，效果相同； - 堆栈中你会看到两层：外层是
UndeclaredThrowableException（来自代理类字节码），内层是getCause()返回的真实异常（来自目标方法或method.invoke）。
和 InvocationTargetException 的关系与区别
二者都是反射/代理场景下的“包装异常”，但触发层级不同：
-
InvocationTargetException发生在Method.invoke()内部：只要目标方法抛异常，它就必然包装一层，getCause()就是目标方法抛出的原始异常； -
UndeclaredThrowableException发生在代理类方法返回前：它不关心invoke()是否发生，只校验最终要抛出的异常是否符合接口声明； - 典型嵌套链是：
UndeclaredThrowableException→InvocationTargetException→ArithmeticException（若目标方法里写了1/0且未声明异常）。
