GenericService.$invoke 不抛出业务异常，而是返回 Object；服务端 throws 异常会被序列化透传，非 Map 形式；ExceptionMap 是自定义封装，可通过 instanceof Throwable 判断后手动提取字段构建。
在 Dubbo 泛化调用中，GenericService.$invoke 方法本身**不会直接抛出业务异常（即 throws 声明的 checked exception）**，它统一返回 Object 类型结果；而服务端 throws 声明的异常，在泛化调用场景下，默认会被 Dubbo 序列化为一个 Exception 实例并作为响应体的一部分返回，**不是以 map 形式主动“返回 ExceptionMap”**。
但你提到的 “ExceptionMap”，通常是指 Dubbo 在泛化调用失败时，将异常信息（如类名、消息、堆栈等）封装成一个 Map<String, Object> 结构用于透传 —— 这并非 Dubbo 内置标准行为，而是部分团队在自定义异常处理器或泛化调用封装层中做的适配。下面分情况说明如何实现类似效果：
1. 服务端 throws 的异常会自动被 Dubbo 包装为 RpcException 或业务异常对象
Dubbo 默认行为是：只要服务端方法声明了 throws XxxException，且实际抛出了该异常（或其子类），Dubbo 会将其序列化后透传给消费者。消费者收到的不是 ExceptionMap，而是一个反序列化的 XxxException 实例（前提是消费者 classpath 有该异常类）。
- 若消费者没有该异常类 → Dubbo 降级为
RuntimeException，附带简单提示（如 "Got unchecked exception..."） - 若启用了
generic=true调用 → 消费者无法直接强转为具体异常类型，只能通过反射或通用方式提取信息
2. 在泛化调用中手动解析异常为 Map（推荐做法）
由于 GenericService.$invoke 返回的是 Object，你需要显式判断是否为异常，并提取关键字段组装成 Map：
立即学习“Java免费学习笔记（深入）”；
Object result = genericService.$invoke("methodName", new String[]{"java.lang.String"}, new Object[]{"arg1"});
if (result instanceof Throwable) {
Throwable t = (Throwable) result;
Map<String, Object> exceptionMap = new HashMap<>();
exceptionMap.put("className", t.getClass().getName());
exceptionMap.put("message", t.getMessage());
exceptionMap.put("cause", t.getCause() != null ? t.getCause().getClass().getName() : null);
exceptionMap.put("stackTrace", Arrays.toString(t.getStackTrace()));
// 可选：递归收集 cause 链
}
3. 通过自定义 Filter + ResultWrapper 统一包装异常为 Map
如果希望所有泛化调用失败都返回标准化 ExceptionMap，可在服务提供方添加 Filter，拦截异常并替换为 Map 结构（需配合消费者端约定解析逻辑）：
- Provider 端 Filter 中 catch 异常，构造
Map<String,Object>，再用Result.setAttachments(...)或直接替换Result.getValue()为该 Map - Consumer 端泛化调用后，先检查
result instanceof Map且含特定 key（如"error"），再按约定解析 - 注意：这会破坏 Dubbo 原生异常传播机制，需双方协同升级，不建议覆盖核心协议
4. 使用 Dubbo 3.x 的 Triple 协议 + Error Descriptor（进阶方案）
Dubbo 3 引入基于 gRPC 的 Triple 协议，支持标准 error code 和 detail message 扩展。你可以定义 Protobuf ExceptionDetail 消息体，在泛化调用中通过 status.code() 和 status.details() 提取结构化异常信息，再转为 Map —— 更规范，但需升级协议和改造序列化逻辑。
不复杂但容易忽略：泛化调用本质是弱类型通信，异常处理必须靠“约定优于配置”。想稳定返回 ExceptionMap，最轻量的方式就是在调用后加一层 instanceof Throwable 判断 + 字段提取封装，无需改框架或协议。
