真实场景描述

讯享网

那么我们把业务相关去掉,抽取一个最简模型.我们在公司,一般都会有自己的自定义异常,然后这个自定义异常一般放在common.jar给其他模块依赖,比如我这里定义一个HelloException

public class HelloException extends RuntimeException { public HelloException() { } public HelloException(String message) { super(message); } } 复制代码

然后我们写一个最简单的Dubbo的demo,如下

interface

讯享网public interface DemoService { String sayHello(String name); } 复制代码

provider

public class DemoServiceImpl implements DemoService { public String sayHello(String name) { throw new HelloException("公众号:肥朝"); } } 复制代码

consumer

讯享网public class DemoAction { private DemoService demoService; public void setDemoService(DemoService demoService) { this.demoService = demoService; } public void start() throws Exception { try { String hello = demoService.sayHello("公众号:肥朝"); } catch (HelloException helloException) { System.out.println("这里捕获helloException异常"); } } } 复制代码

按照聊天记录的描述,此时consumer调用provider,provider抛出HelloException.但是consumer捕获到的,却不是HelloException.

那么我们运行看看

果然如该同事所言.为什么会这样呢?之前没看过肥朝Dubbo源码解析系列的同学这种时候往往采用最低效的解决办法,把异常栈往微信群一丢,各种求助.但是往往毫无收获,然后感叹社会为何如此冷漠!

但是相信公众号的老粉丝们早已掌握阅读源码的技能,和肥朝一样坐怀不乱,九浅一深直入源码.出现异常我们首先看一下异常栈

除非撸多了看不清(建议戒撸),否则这行异常和肥朝一样,就像漆黑中的萤火虫一样,那么鲜明,那么出众

com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:108) 复制代码

那么我们一探究竟

讯享网public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { try { Result result = invoker.invoke(invocation); if (result.hasException() && GenericService.class != invoker.getInterface()) { try { Throwable exception = result.getException(); // 如果是checked异常，直接抛出 if (! (exception instanceof RuntimeException) && (exception instanceof Exception)) { return result; } // 在方法签名上有声明，直接抛出 try { Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes()); Class<?>[] exceptionClassses = method.getExceptionTypes(); for (Class<?> exceptionClass : exceptionClassses) { if (exception.getClass().equals(exceptionClass)) { return result; } } } catch (NoSuchMethodException e) { return result; } // 未在方法签名上定义的异常，在服务器端打印ERROR日志 logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception); // 异常类和接口类在同一jar包里，直接抛出 String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface()); String exceptionFile = ReflectUtils.getCodeBase(exception.getClass()); if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)){ return result; } // 是JDK自带的异常，直接抛出 String className = exception.getClass().getName(); if (className.startsWith("java.") || className.startsWith("javax.")) { return result; } // 是Dubbo本身的异常，直接抛出 if (exception instanceof RpcException) { return result; } // 否则，包装成RuntimeException抛给客户端 return new RpcResult(new RuntimeException(StringUtils.toString(exception))); } catch (Throwable e) { logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e); return result; } } return result; } catch (RuntimeException e) { logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost() + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName() + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e); throw e; } } 复制代码

手机上阅读源码或许并不友好,但是没关系,上面都有完善的中文注释,他想表达的意思如下:

1.如果是checked异常，直接抛出.很明显,我们的HelloException是RuntimeException,不符合

2.在方法签名上有声明，直接抛出.很明显,我们接口并未声明该异常,不符合

3.异常类和接口类在同一jar包里，直接抛出.很明显,我们的异常类是在common.jar的,接口是在api.jar的,不符合

4.是JDK自带的异常，直接抛出.很明显,这个HelloException是我们自定义的,不符合

5.是Dubbo本身的异常(RpcException)，直接抛出.很明显,这个HelloException是我们自定义的,和RpcException几乎没有半毛钱关系.

6.否则，包装成RuntimeException抛给客户端.因为以上5点均不满足,所以该异常会被包装成RuntimeException异常抛出(重要)

这也就是为什么我们catchHelloException是catch不到的,因为他包装成RuntimeException了

Dubbo为什么这么设计

也许你看到这里会觉得这个判断好坑.Dubbo为什么要这么设计?我们看源码,最重要的是知道作者为什么这么设计,只有知道为什么这么设计才是经过了深度的思考,否则看时高潮,看后就忘.讲清楚为什么这么设计,也是大家关注肥朝公众号的一个重要原因.

其实Dubbo的这个考虑,是基于序列化来考虑的.你想想,如果provider抛出一个仅在provider自定义的一个异常,那么该异常到达consumer,明显是无法序列化的.所以你注意看Dubbo的判断.我们来看下他的判断

1.checked异常和RuntimeException是不同类型,强行包装可能会出现类型转换错误,因此不包,直接抛出

2.方法签名上有声明.方法签名上有声明,如果这个异常是provider.jar中定义的,因为consumer是依赖api.jar的,而不是依赖provider.jar.那么编译都编译不过,如果能编译得过,说明consumer是能依赖到这个异常的,因此序列化不会有问题,直接抛出

3.异常类和接口类在同一jar包里.provider和consumer都依赖api,如果异常在这个api,那序列化也不会有问题,直接抛出

4.是JDK自带的异常，直接抛出.provider和consumer都依赖jdk,序列化也不会有问题,直接抛出

5.是Dubbo本身的异常(RpcException)，直接抛出.provider和consumer都依赖Dubbo,序列化也不会有问题,直接抛出

6.否则，包装成RuntimeException抛给客户端.此时,就有可能出现我说的那种,这个异常是provider.jar自定义的,那么provider抛出的时候进行序列化,因为consumer没有依赖provider.jar,所以异常到达consumer时,根本无法反序列化.但是包装成了RuntimeException异常则不同,此时异常就是JDK中的类了,到哪都能序列化.

如何解决

既然都知道了原理了,那么很好解决,我随便列举一下,比如从规范上要求业务方接口声明`HelloException

注意：本文归作者所有，未经作者允许，不得转载