Dubbo 的 ExceptionFilter 默认将未声明的受检异常包装为 RuntimeException（保留 cause），因 RPC 跨 JVM 无法校验 throws 声明，避免消费方代理方法抛出未声明异常导致 JVM 报错；已声明或 RpcException 类型则直接透传。
Dubbo 的 ExceptionFilter 默认会将未声明的受检异常（即方法签名中未 throws 的 checked exception）包装为 RuntimeException，具体是包装成 RuntimeException 的子类 RuntimeException 或其包装类 RpcException，而非直接抛出原始受检异常。
为什么需要包装未声明的受检异常
Dubbo 的远程调用协议（如 Dubbo 协议）基于 Java 的动态代理和序列化机制，服务提供方抛出的异常需反序列化回消费方。但 Java 的方法签名约束在 RPC 场景下无法天然跨 JVM 生效：消费方调用接口时，编译器只检查本地接口声明的 throws 异常；若服务端实际抛出未声明的受检异常（比如 IOException），消费方代理方法并未声明该异常，JVM 不允许直接 throw，否则编译或运行时会报错。
ExceptionFilter 的默认包装逻辑
Dubbo 内置的 ExceptionFilter（位于 org.apache.dubbo.rpc.filter.ExceptionFilter）在捕获异常后，按以下规则处理：
- 若异常是
RuntimeException或Error，原样抛出； - 若异常是未在接口方法
throws子句中声明的受检异常，则将其包装为RuntimeException，实际使用的是new RuntimeException(cause)，且保留原始异常作为 cause； - 若异常已在接口方法中声明（即属于
throws列表中的类型或其子类），则不包装，直接透传（经序列化后由消费方 re-throw）； -
RpcException及其子类始终不包装，直接透传。
如何自定义包装行为
若需改变默认包装方式（例如统一包装为特定业务异常、添加日志上下文、过滤敏感信息），可实现自定义 Filter：
- 继承
org.apache.dubbo.rpc.Filter，重写invoke方法，在invoker.invoke(invocation)后捕获异常； - 判断异常是否为未声明的受检异常：
!isDeclaredException(throwable, invoker.getInterface(), invocation.getMethodName())； - 手动构造新异常，如
new BizRuntimeException("RPC 调用异常", throwable)，再 throw； - 通过 SPI 扩展注册该 Filter，并配置
filter="yourExceptionFilter"（Provider 端）。
注意事项
包装后异常的 cause 链仍完整，消费方可通过 e.getCause() 获取原始受检异常；但消费方代码无法用 catch (IOException e) 直接捕获——必须 catch RuntimeException 或其子类；若需强类型感知，应在服务接口中显式声明所有可能抛出的受检异常，这是 Dubbo 推荐的最佳实践。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
