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行为自定义异常,则要引入自定义的包等).
这样就从根本上解决了异常处理的问题.后续有其他问题,也可以直接修改.