作者 | 肥朝

责编 | 郭芮

17年的时候，因为一时冲动没把持住，结合面试题写了一个系列的Dubbo源码解析，结果颇受欢迎。根据我的面试经验而言，能在简历上写上原理、源码等关键词的，都是非常具备核心竞争力的。

上周，一位读者就和我交流了下面试情况：

把简历按照你说的那样改了下，感觉投了就有面试机会......

确实，面试的时候把源码一波分析，绝对能令面试官虎躯一震！然而在一阵前戏过后，不料面试官突然来了句令剧情发生了反转：

“你对Dubbo源码这么熟悉，那请问你使用的时候有没有遇到什么坑？”

——毫无准备的他顿时面临着唬住了50K、唬不住就只能5K的局面，慌了！

论如何反杀

相信大家面试都遇到过类似问题，因为源码解析网上很多，很多人"考前突击"一下。但是遇到喜欢问细节的面试官，终究难逃法眼，无处遁形。

遇到这个问题，我们如何反杀一波？下面我们就来描述一波真实场景。毕竟只有拥有真实场景的源码实战（非常重要），遇到这类问题，才不至于出现猛虎落泪的情形。

真实场景描述

以这个聊天记录中的真实场景为例：

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

 1public class HelloException extends RuntimeException { 2 3    public HelloException() { 4    } 5 6    public HelloException(String message) { 7        super(message); 8    } 910}

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

interface

1public interface DemoService {23    String sayHello(String name);45}

provider

1public class DemoServiceImpl implements DemoService {23    public String sayHello(String name) {4        throw new HelloException("公众号:肥朝");5    }67}

consumer

 1public class DemoAction { 2 3    private DemoService demoService; 4 5    public void setDemoService(DemoService demoService) { 6        this.demoService = demoService; 7    } 8 9    public void start() throws Exception {10        try {11            String hello = demoService.sayHello("公众号:肥朝");12        } catch (HelloException helloException) {13            System.out.println("这里捕获helloException异常");14        }15    }1617}

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

那么我们运行看看：

果然如其所言。为什么会这样呢？很多同学这种时候往往会采用最低效的解决办法，把异常栈往微信群一丢，各种求助，但是往往毫无收获，然后感叹社会为何如此冷漠！

但是如果掌握了阅读源码的技能，就能够直入源码。出现异常我们首先看一下异常栈：

相信一眼望去，这行异常十分鲜明和出众：

1com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:108)

那么我们一探究竟：

1    public Result invoke(Invoker<?> invoker, Invocation invocation) throws RpcException { 2        try { 3            Result result = invoker.invoke(invocation); 4            if (result.hasException() && GenericService.class != invoker.getInterface()) { 5                try { 6                    Throwable exception = result.getException(); 7 8                    // 如果是checked异常，直接抛出 9                    if (! (exception instanceof RuntimeException) && (exception instanceof Exception)) {10                        return result;11                    }12                    // 在方法签名上有声明，直接抛出13                    try {14                        Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());15                        Class<?>[] exceptionClassses = method.getExceptionTypes();16                        for (Class<?> exceptionClass : exceptionClassses) {17                            if (exception.getClass().equals(exceptionClass)) {18                                return result;19                            }20                        }21                    } catch (NoSuchMethodException e) {22                        return result;23                    }2425                    // 未在方法签名上定义的异常，在服务器端打印ERROR日志26                    logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()27                            + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()28                            + ", exception: " + exception.getClass().getName() + ": " + exception.getMessage(), exception);2930                    // 异常类和接口类在同一jar包里，直接抛出31                    String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());32                    String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());33                    if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)){34                        return result;35                    }36                    // 是JDK自带的异常，直接抛出37                    String className = exception.getClass().getName();38                    if (className.startsWith("java.") || className.startsWith("javax.")) {39                        return result;40                    }41                    // 是Dubbo本身的异常，直接抛出42                    if (exception instanceof RpcException) {43                        return result;44                    }4546                    // 否则，包装成RuntimeException抛给客户端47                    return new RpcResult(new RuntimeException(StringUtils.toString(exception)));48                } catch (Throwable e) {49                    logger.warn("Fail to ExceptionFilter when called by " + RpcContext.getContext().getRemoteHost()50                            + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()51                            + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);52                    return result;53                }54            }55            return result;56        } catch (RuntimeException e) {57            logger.error("Got unchecked and undeclared exception which called by " + RpcContext.getContext().getRemoteHost()58                    + ". service: " + invoker.getInterface().getName() + ", method: " + invocation.getMethodName()59                    + ", exception: " + e.getClass().getName() + ": " + e.getMessage(), e);60            throw e;61        }62    }

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

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

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

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

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

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

• 否则，包装成RuntimeException抛给客户端。因为以上5点均不满足，所以该异常会被包装成RuntimeException异常抛出（重要）。

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

Dubbo为什么这么设计？

也许你看到这里会觉得这个判断好坑。Dubbo为什么要这么设计？我们看源码，最重要的是知道作者为什么这么设计，只有知道为什么这么设计才是经过了深度的思考，否则只能看后就忘。

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

我们来看下它的判断：

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

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

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

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

• 是Dubbo本身的异常（RpcException），直接抛出。provider和consumer都依赖Dubbo，序列化也不会有问题，直接抛出。

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

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

写在最后

当然我面试的时候，也曾经被问过类似问题：你用XXX有没有遇到过什么坑？在一波操作猛如虎的分析下，面试官说：“你真帅”。

我会心一笑，结果他却说：“你笑起来更帅”！

作者：肥朝，同名公众号（ID：feichao_java）作者。目前从事基础架构相关工作，长期分享源码解析，真实场景源码实战。白天是码农，晚上是知识服务者。

声明：本文为作者投稿，版权归其个人所有。

 热 文 推 荐 

☞ 西安到底需不需要互联网？

☞ Google 要进军游戏行业了？！

☞ 华为京东联手，火拼小米生态链！

☞ 315 后，等待失业的程序员

☞ 套路贷+套路培训，IT 培训机构造假术大公开 | 程序员有话说

那位13岁就当上老板的开发者是如何炼成的？

☞ 好莱坞大片! 为躲避死亡威胁, 只用15步, 这个密码朋克大叔就从世界"消失"了...

确认！贾扬清加盟阿里，任技术副总裁

都道业务提升坑大事儿多，但英特尔云方案却说“简单”

☞ Python 爬取蔡徐坤的 10 万转发数据，竟是假流量？

System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"

喜欢就点击“在看”吧！