记一次Dubbo的异常处理过程。
现象：业务团队报送，服务端定义一个BuinessException，继承与RunTimeException，服务端执行时抛出该异常，但是客户端捕捉不到该异常。
记录：把代码down下来，开始模拟，发现客户端收到了Exception，但是却是RunTimeException，直觉感觉可能是Dubbo的异常处理这一块儿出了问题，或者是我们的服务端没有按照一定的规则书写，看了服务端的接口方法签名，发现没有显示的抛出异常，直觉感觉，如果是没有显示的抛出异常，该接口在被Dubbo的动态代理执行invoke方法时，能获取到ExceptionType吗？答案，感觉是不能的。
另写一套代码保证模拟，竟然是能捕捉到的。为什么呢？下文解释。
如果获取不到，Dubbo会怎么处理呢？是不是会new 一个 RunTimeException返回回来呢？我们带着这些疑问看一下Dubbo的源码。
代码就在ExceptionFilter里面，我们打开看一下其实就很清楚了。
这个invoke方法时服务端的代理（Dubbo的动态代理也有点儿意思，改天咱们再写一个）对象代码的执行方法，那可以通过method拿到相关异常信息。
1、判断是否不是RunTimeException 并且 没有实现GengricService。我们没有，所以没有返回我们的BuinessException。
2、如果是check异常直接返回，我们也不是。所以没有返回我们的BuinessException。
3、
如果方法上有显示抛出，直接返回，很不幸，我们恰巧少了。
4、如果在同一个jar包里，直接返回（这个就是我们单写的为什么成功的原因）
5、Jdk的直接返回异常，我们自定义的。
6、Dubbo本身的，直接返回，我们不是。
7、所以，最后我们被new 了一个 RunTimeException 回来。
总结，其实是有日志的，只不过没有见过，然后也大意忽略了。
解决方案，将没有添加异常抛出的方法加上（造成上游调用端修改，需要一样抛出或者try/catch，那也是没办法的事，接口本来定义的就不规范）