dubbo全局异常处理_Dubbo 学习1——Service自定义异常捕获不到问题
阅读：[《面试官问我，使用Dubbo有没有遇到一些坑？我笑了。》](https://mp.weixin.qq.com/s?__biz=MzU0OTE4MzYzMw==&mid=2247486101&idx=1&sn=59ffc6181fed33866ace4fcdee40bb3e) 受到启发，解决问题，记录一下。
问题简单描述：
> 业务方使用Dubbo，自定义异常类型``XXXException``(继承自RuntimeException )，抛出异常后无法在调用处被捕获到。。。
通过分析异常堆栈信息，发下类似以下信息：
```java
com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:xxx)
```
Dubbo 相关源码如下：
```java
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 异常，直接抛出。很明显，业务的``XXXException``是``RuntimeException``，不符合。
- 2.在方法签名上有声明，直接抛出。
- 3.异常类和接口类在同一jar包里，直接抛出。
- 4.是JDK自带的异常，直接抛出。很明显，这个``XXXException``是业务自定义的，不符合。
- 5.是Dubbo本身的异常(``RpcException``)，直接抛出。很明显，这个``XXXException``是业务自定义的，和``RpcException``几乎没有半毛钱关系。
- 6.否则，包装成``RuntimeException``抛给客户端。因为以上5点均不满足，所以该异常会被包装成``RuntimeException``异常抛出(重要)
这也就是为什么我们catch ``XXXException``是 catch 不到的,因为他包装成``RuntimeException``了。
# 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中的类了,到哪都能序列化.
# 如何解决
了解了原理，就很好解决了，比如：从规范上要求业务方接口(方法签名)声明``XXXException``。