Dubbo默认将不满足透传条件的异常封装为GenericException；要原样传递，需满足受检异常、接口throws声明、同模块定义等条件，并确保序列化兼容；也可通过Provider端Filter主动透传或Consumer端解析GenericException还原信息。
客户端收到 GenericException，本质是 Dubbo 对非标准异常做了兜底封装——它没把你的自定义异常原样透传过去，而是“降级”成泛化异常包装体。这不是 bug，而是默认行为；要让它原样传递，得满足 Dubbo 的异常透传规则或主动干预。
确认异常是否满足 Dubbo 原样透传条件
Dubbo 服务端抛出的异常，只有满足以下任一条件，才会被消费者原样接收到（而非转为 GenericException 或 RuntimeException）：
- 异常类是受检异常（即继承
Exception，且不是RuntimeException子类） - 该异常类在服务接口的
throws子句中显式声明 - 异常类与服务接口定义在同一个 Maven 模块（jar 包）中（例如 common-api 模块同时含接口和异常）
- 异常类全限定名以
java.或javax.开头（不推荐，违反规范） - 异常类是 Dubbo 自身异常（如
RpcException）
补全序列化兼容性要求
即使异常类满足上述条件，若使用 Hessian2（Dubbo 默认序列化器），还必须保证它可被反序列化：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 自定义异常类必须有 public 无参构造方法
- 所有字段需为可序列化类型，或标记为
transient - 若用 Dubbo 3.x，还需将异常类加入
security/serialize.allowlist配置（否则报Serialized class xxx is not in allow list）
用 Filter 主动拦截并透传异常
当无法调整模块结构或异常继承关系时，最通用可靠的方案是在 provider 端添加自定义 Filter，绕过默认的 ExceptionFilter 封装逻辑：
立即学习“Java免费学习笔记（深入）”；
- 实现
org.apache.dubbo.rpc.Filter接口，@Activate(group = Constants.PROVIDER, order = -10000)确保优先执行 - 在
invoke()中捕获业务异常，构建RpcResult并调用setException()直接设置原始异常对象 - 避免触发 Dubbo 默认的
ExceptionFilter（它会把不符合条件的异常 toString 后包成RuntimeException）
消费端适配泛化异常场景
如果仍收到 GenericException（比如用了泛化调用 GenericService），可通过其字段还原原始异常信息：
-
genericException.getExceptionClass()获取原始异常类名 -
genericException.getExceptionMessage()获取原始 message -
genericException.getExceptionStackTrace()获取堆栈字符串（需自行解析） - 建议在 consumer 端统一做映射：根据类名 new 出对应异常实例，或转为标准错误码+提示
