dubbo(四)异常处理

最新推荐文章于 2024-07-11 21:52:59 发布

m0_67392126

最新推荐文章于 2024-07-11 21:52:59 发布

阅读量1.3k

点赞数

分类专栏： java 文章标签： dubbo java java-zookeeper 数据库后端

本文链接：https://blog.csdn.net/m0_67392126/article/details/126327822

版权

java 专栏收录该内容

273 篇文章 5 订阅

订阅专栏

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接口.(我没试过这种方式,应该是要自己实现 $in v o k e () 方法, 网上说直接把$ 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 more
Caused 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 more
Caused 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[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-TJTpaeOZ-1660432261097)(http://static.blog.csdn.net/xheditor/xheditor_emot/default/laugh.gif)]).

	<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了.如下图: