– 这里的dubbo 可泛指 所有rpc框架
–比如自定义异常类型是MyEx, 以及myEx可以转化为MyResult
– 需求: 凡是请求链路中抛出的MyEx需要自动及时或最终转化为 自定义的MyResult返回
– 1. spring 提供 controller端的全局异常捕获. 这一步简单
– 2. dubbo 需要 将MyEx 传输回来
这里就有点需要考虑的, 因为
dubbo 第一要义是不能违反序列化异常, 序列化成功的前提是dubbo上下游双方起码都要有这个异常类型, 才能放心的回传, 不然provider抛出一个只在provider有的异常类, 在consumer端是没有这个异常类的, 自然类加载反射序列化都会失败 (ps: 虽然 dubbouble双方是是面向同一方法签名(接口)的(即使返回子类也是强转成父类, 隐藏子类域 todo 这里研究下 consumer如果是独有的子类, 这个dubbo序列化和反序列化会怎们做), 但是方法签名可限制不住人家consumer抛什么具体类型的异常)
所以dubbo的做法:
当然可以直接全部 new RuntimeException(StringUtils.toString(exception)), 但这样太粗鲁了.
问题的关键, 就是 provider端到底一定依赖
1.“directly throw if it’s checked exception”：意思就是说，如果该异常是检查型异常，则直接抛出
2.“directly throw if the exception appears in the signature”：大概意思是，如果接口的方法声明中抛出了该异常，则直接抛出
3.“for the exception not found in method’s signature, print ERROR message in server’s log”：意思是，如果接口的方法中没有声明该异常，则打印ERROR日志
4.“directly throw if exception class and interface class are in the same jar file”：大概意思是：如果异常类和接口类在同一个jar中，则直接抛出
5.“directly throw if it’s JDK exception”：意思是，如果是JDK中的异常，则直接抛出
6.“directly throw if it’s dubbo exception”：如果是dubbo的异常，则直接抛出
7.“otherwise, wrap with RuntimeException and throw back to the client”：否则，包装成RuntimeException抛出给客户端
原文链接：https://blog.csdn.net/shuux666/article/details/123889835
– 所以 仅仅dubbo自带的异常转换是无法完成这一点的.
– 我们需要 dubbo统一异常处理 (实现dubbo的filter , 或者直接spring 的aop)
- https://www.cnblogs.com/zcz527/p/7655235.html
把捕获到的 MyEx信息 , 转化为 MyResult (前提是 dubbo方法声明的返回值类型是MyResult了 , 不然也没有办法转(方法签名不一致, 转了后provider端解析就会报错), 这就是开发手册为啥规定建议rpc一定要 MyResult的原因之一吧 )… 如果不是MyResult的类型, 就没法办了
