dubbo异常处理(一)

版权声明:本文为博主原创文章,遵循 CC 4.0 by-sa 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/yangzaizi/article/details/80638306

dubbo的异常处理网上描述的文章很多,复制黏贴也不在少数.在这里记录下自己的一些体会.

还是带着问题(目录)来写吧.


1.dubbo官方推荐的异常处理方式是什么?

2.dubbo处理异常的逻辑是什么样的?为什么要这样处理?

3.抛出自定义异常有哪些方式?

4.在dubbo:provider中设置filter="-exception", 去掉异常的filter会怎么样?

5.最终采用的异常处理方案



1.dubbo官方推荐的异常处理方式是什么?

在dubbo官方文档的服务化最佳实践中,推荐的处理方式如下:



2.dubbo处理异常的逻辑是什么样的?为什么要这样处理?

dubbo的异常处理类是com.alibaba.dubbo.rpc.filter.ExceptionFilter 类,源码这里就不贴了.归纳下对异常的处理分为下面几类:

1)如果provider实现了GenericService接口,直接抛出

2)如果是checked异常,直接抛出

3)在方法签名上有声明,直接抛出

4)异常类和接口类在同一jar包里,直接抛出

5)是JDK自带的异常,直接抛出

6)是Dubbo本身的异常,直接抛出

7)否则,包装成RuntimeException抛给客户端

网上有些文章对7)的处理有疑问,不理解原因,其实就是为了防止客户端反序列化失败.前面几种情况都能保证反序列化正常.


3.抛出自定义异常有哪些方式?

抛出自定义异常其实就是使用上面2中的逻辑.所以相对应的有以下几种方式:

1)provider实现GenericService接口.(我没试过这种方式,应该是要自己实现$invoke()方法,网上说直接把$invoke()方法废弃掉不知道是怎么处理的,直接返回null肯定是不行的)

2)自定义异常声明为checked异常(这没啥说了,不过一般自定义异常都是unchecked)

3)在方法签名上声明抛出异常(这种基本上所有接口都要写,麻烦)

4)异常类和接口类在同一jar包里(存在链式调用时,这种可能不适用)

5)自定义异常的包名以java.或javax.开头(dubbo判断jdk自带异常的条件,一般项目都有自己的命名规范,这样干的估计很少)


除了上面对应的,还可以用一种奇葩的方式,直接去掉异常的filter,如下:

6) <dubbo:provider filter="-exception" />


4.在dubbo:provider中设置filter="-exception", 去掉异常的filter会怎么样?

我在处理自定义异常的时候,觉得3中提到前5种方式都不太适合,所以使用了这种方式.

这种方式对provider中抛出的异常不做任何处理,直接返回给consumer,会遇到一些奇怪的问题;

例如,在provider中有以下代码:

[java] view plain copy
  1. String respone = "avs";  
  2. JSONObject resultjson = JSONObject.fromObject(respone);  

这段代码会抛出 net.sf.json.JSONException ,但是在provider中不会打印任何异常信息.

而在consumer中,会报出下面的错误:

[java] view plain copy
  1. com.alibaba.com.caucho.hessian.io.HessianFieldException: org.apache.commons.lang.exception.NestableRuntimeException.delegate: 'org.apache.commons.lang.exception.NestableDelegate' could not be instantiated  
  2.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:671)  
  3.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializer.deserialize(JavaDeserializer.java:400)  
  4.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:233)  
  5.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:157)  
  6.     at com.alibaba.com.caucho.hessian.io.SerializerFactory.readObject(SerializerFactory.java:397)  
  7.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2070)  
  8.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2005)  
  9.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1990)  
  10.     at com.alibaba.dubbo.common.serialize.support.hessian.Hessian2ObjectInput.readObject(Hessian2ObjectInput.java:88)  
  11.     at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:92)  
  12.     at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:109)  
  13.     at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:97)  
  14.     at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:126)  
  15.     at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:87)  
  16.     at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:46)  
  17.     at com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:134)  
  18.     at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80)  
  19.     at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564)  
  20.     at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559)  
  21.     at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274)  
  22.     at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261)  
  23.     at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349)  
  24.     at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:280)  
  25.     at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:200)  
  26.     at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108)  
  27.     at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44)  
  28.     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)  
  29.     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)  
  30.     at java.lang.Thread.run(Thread.java:745)  
  31. Caused by: com.alibaba.com.caucho.hessian.io.HessianProtocolException: 'org.apache.commons.lang.exception.NestableDelegate' could not be instantiated  
  32.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeserializer.java:275)  
  33.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:155)  
  34.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2067)  
  35.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1592)  
  36.     at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1576)  
  37.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializer.deserialize(JavaDeserializer.java:396)  
  38.     ... 27 more  
  39. Caused by: java.lang.reflect.InvocationTargetException  
  40.     at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)  
  41.     at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)  
  42.     at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)  
  43.     at java.lang.reflect.Constructor.newInstance(Constructor.java:526)  
  44.     at com.alibaba.com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeserializer.java:271)  
  45.     ... 32 more  
  46. Caused by: java.lang.IllegalArgumentException: The Nestable implementation passed to the NestableDelegate(Nestable) constructor must extend java.lang.Throwable  
  47.     at org.apache.commons.lang.exception.NestableDelegate.<init>(NestableDelegate.java:112)  
  48.     ... 37 more  

这是个因为异常传递引起的错误,原异常信息也丢失了,无法定位问题.


为了解决这个问题,想到的方案是在provider中,把所有入口方法都进行catch处理,转换为自定义异常.

想当然的就用spring的AOP功能来实现.(解决一个bug,引入另外的bug大笑).

[html] view plain copy
  1. <bean id="serviceEx" class="com.dingcheng.common.exception.ServiceExceptionHandler" />    
  2. <aop:config>  
  3.     <aop:aspect id="exServiceAop" ref="serviceEx">    
  4.            <aop:pointcut id="exParam" expression="execution(* com.dingcheng.*.service.*Service.*(..))" />    
  5.            <aop:after-throwing pointcut-ref="exParam" method="doThrowing" throwing="ex" />    
  6.        </aop:aspect>   
  7. </aop:config>   


使用AOP进行异常拦截后引发了另外一个问题,就是ServiceA.a()里面调用ServiceB.b()这种情况.

b()里抛出异常,aop处理一次,然后a再抛出异常,aop再处理一次,多次调用就多次处理.

理想的解决方案是像事务管理那样可以配置传播性,但是这个不支持这种配置,

所以这种方案也不够好.


5.最终采用的异常处理方案

抛出一个自定义异常有这么麻烦吗? 主要原因是dubbo没有支持的原因.

既然这样,我们把dubbo变的支持不就可以了?

是的.把源码改一下就OK了.如下图:



在异常处理这里,加上自定义异常处理的代码.

或者直接将112行的RuntimeException替换成自己的自定义异常!


修改源码后,可以替换maven仓库的jar,或者是在自己项目里面建一个ExceptionFilter,包名和dubbo的相同,用来覆盖掉dubbo的

(如果替换112行为自定义异常,则要引入自定义的包等).


这样就从根本上解决了异常处理的问题.后续有其他问题,也可以直接修改.

展开阅读全文

没有更多推荐了,返回首页