开发者

dubbo将异常转换成RuntimeException的原因分析 ExceptionFilter

目录
  • 问题
  • 代码分析
  • 结论
  • 思考
  • 最后

问题

开发过程中,发现服务提供者抛出了自定义的BusinessException,到了消费者这边,却变成了RuntimeExcept编程ion。

客户端这边有BusinessException这个类,提供者抛出的也是这个类的异常,为什么会被转成RpcExcep编程客栈tion呢?

代码分析

看ExceptionFilter的代码:

dubbo将异常转换成RuntimeException的原因分析 ExceptionFilter

重点就在圈起来的3个地方:

1、有异常,而且接口不能是GenericService才需要判断是否需要转换成RuntimeException,不然直接返回result。

2、如果是受检异常,则不转换,直接返回。

3、如果不是受检异常,则需要判断该异常是否在方法上声明抛出,如果有声明就不转换,直接返回。

如果不是上面的这三种情况,就会去到兜底逻辑:

dubbo将异常转换成RuntimeException的原因分析 ExceptionFilter

兜底判断也是有三点:

1、判断接口和异常是否在一个jar包中,如果是在一个jar包,不需要转换成RuntimeException。

2、如果异常是Java异常,不需要处理。

3、异常类型是RpcException,不需要处理。

如果这三者都不满足,就会到达代码:

return new RpcResult(new RuntimeException(StringUtils.toString(exception)));

异常会被转成字符串,作python为RuntimeException的构造函数入参。

结论

由于BusinessException是在一个通用工具包中,和接口不在一个jar包中,BusinessException也不是受检异常,所以不满足不转换的条件。

要让提供者抛出的异常不被转成RuntimeExcep开发者_Python入门tion,可以在定义方法的时候,声明 throws BusinessExceptiojavascriptn。

思考

为什么dubbo要这样判断是否需要转成RuntimeException呢?

个人觉得,依据是消费者能否反序列化成对应的异常类,消费端android有抛出的这个异常类,就能成功反序列化。

1、能抛出受检异常,那么在方法上必然声明了抛出该异常,客户端包里会有该异常类

2、同理,如果不是受检异常,但是在方法上声明了,客户端也会有

3、如果接口和异常类是在同一个jar吧,说明客户端包里有异常类

4、jdk自己的异常类,自然是存在的

5、RpcException是dubbo自己的异常类,消费者必然也有

最后

以上为个人经验,希望能给大家一个参考,也希望大家多多支持我们。

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新开发

开发排行榜