dubbo 四 异常处理

               

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中有以下代码:

  String respone = "avs";  JSONObject resultjson = JSONObject.fromObject(respone);

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

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

com.alibaba.com.caucho.hessian.io.HessianFieldException: org.apache.commons.lang.exception.NestableRuntimeException.delegate: 'org.apache.commons.lang.exception.NestableDelegate' could not be instantiated at com.alibaba.com.caucho.hessian.io.JavaDeserializer.logDeserializeError(JavaDeserializer.java:671) at com.alibaba.com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializer.deserialize(JavaDeserializer.java:400) at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:233) at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:157) at com.alibaba.com.caucho.hessian.io.SerializerFactory.readObject(SerializerFactory.java:397) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2070) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:2005) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1990) at com.alibaba.dubbo.common.serialize.support.hessian.Hessian2ObjectInput.readObject(Hessian2ObjectInput.java:88) at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:92) at com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcResult.decode(DecodeableRpcResult.java:109) at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCodec.decodeBody(DubboCodec.java:97) at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:126) at com.alibaba.dubbo.remoting.exchange.codec.ExchangeCodec.decode(ExchangeCodec.java:87) at com.alibaba.dubbo.rpc.protocol.dubbo.DubboCountCodec.decode(DubboCountCodec.java:46) at com.alibaba.dubbo.remoting.transport.netty.NettyCodecAdapter$InternalDecoder.messageReceived(NettyCodecAdapter.java:134) at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:349) at org.jboss.netty.channel.socket.nio.NioWorker.processSelectedKeys(NioWorker.java:280) at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:200) at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745)Caused by: com.alibaba.com.caucho.hessian.io.HessianProtocolException: 'org.apache.commons.lang.exception.NestableDelegate' could not be instantiated at com.alibaba.com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeserializer.java:275) at com.alibaba.com.caucho.hessian.io.JavaDeserializer.readObject(JavaDeserializer.java:155) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObjectInstance(Hessian2Input.java:2067) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1592) at com.alibaba.com.caucho.hessian.io.Hessian2Input.readObject(Hessian2Input.java:1576) at com.alibaba.com.caucho.hessian.io.JavaDeserializer$ObjectFieldDeserializer.deserialize(JavaDeserializer.java:396) ... 27 moreCaused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:526) at com.alibaba.com.caucho.hessian.io.JavaDeserializer.instantiate(JavaDeserializer.java:271) ... 32 moreCaused by: java.lang.IllegalArgumentException: The Nestable implementation passed to the NestableDelegate(Nestable) constructor must extend java.lang.Throwable at org.apache.commons.lang.exception.NestableDelegate.<init>(NestableDelegate.java:112) ... 37 more

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


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

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

 <bean id="serviceEx" class="com.dingcheng.common.exception.ServiceExceptionHandler" />   <aop:config>  <aop:aspect id="exServiceAop" ref="serviceEx">              <aop:pointcut id="exParam" expression="execution(* com.dingcheng.*.service.*Service.*(..))" />              <aop:after-throwing pointcut-ref="exParam" method="doThrowing" throwing="ex" />          </aop:aspect>  </aop:config> 


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

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

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

所以这种方案也不够好.


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

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

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

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



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

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


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

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


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



           
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值