dubbo全局异常处理_详解Dubbo无法处理自定义异常及解决方案
問題描述
Dubbo有一個比較奇怪的問題，目前不知道Apache和Alibaba公司出于什么樣的考慮，貌似一直都沒有一個比較合適的解決方案，問題如下：
項目搭建中你需要自定義一個本地的Exception，命名為比如BusinessException。比較一般的書寫代碼如下：
/**
* @Author linqiang
* @Date 2019/10/24 16:20
* @Version 1.0
* @Description 業務異常類
**/
public class BusinessException extends RuntimeException{
private Integer code;
private String msg;
public BusinessException(Integer code, String msg){
this.code = code;
this.msg = msg;
}
public Integer getCode(){
return code;
}
public String getMsg(){
return msg;
}
}
復制代碼
通常這個BusinessException是要能夠跨模塊使用的，一般放在commons或者core模塊中，同時別的模塊的pom.xml文件引入這些模塊，使得整個項目都可以使用這個BusinessException。
問題來了，如果在A模塊調用了B模塊，B模塊拋出了一個BusinessException，這時A模塊接收到的不是BusinessException，而是一個RuntimeException，而且關于BusinessException的細節已經完全丟失，只會剩下一個類名的描述。
問題原因
關于該問題出現的原因，參考這篇文章，歸納一下，就是在Dubbo的傳輸信息過程中，類ExceptionFilter.java會對Exception做一個過濾，其過濾器的關鍵代碼如下：
// directly throw if it's checked exception
if (!(exception instanceof RuntimeException) && (exception instanceof Exception)) {
return;
}
// directly throw if the exception appears in the signature
try {
Method method = invoker.getInterface().getMethod(invocation.getMethodName(), invocation.getParameterTypes());
Class>[] exceptionClassses = method.getExceptionTypes();
for (Class> exceptionClass : exceptionClassses) {
if (exception.getClass().equals(exceptionClass)) {
return;
}
}
} catch (NoSuchMethodException e) {
return;
}
// for the exception not found in method's signature, print ERROR message in server's log.
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);
// directly throw if exception class and interface class are in the same jar file.
String serviceFile = ReflectUtils.getCodeBase(invoker.getInterface());
String exceptionFile = ReflectUtils.getCodeBase(exception.getClass());
if (serviceFile == null || exceptionFile == null || serviceFile.equals(exceptionFile)) {
return;
}
// directly throw if it's JDK exception
String className = exception.getClass().getName();
if (className.startsWith("java.") || className.startsWith("javax.")) {
return;
}
// directly throw if it's dubbo exception
if (exception instanceof RpcException) {
return;
}
// otherwise, wrap with RuntimeException and throw back to the client
appResponse.setException(new RuntimeException(StringUtils.toString(exception)));
return;
復制代碼
即Dubbo在遇到異常時會這樣處理：
非RuntimeException不處理，直接返回
拋出的是方法上注明的異常，直接返回
如果異常類和接口類在同一jar包，直接返回
java或者javax目錄下的異常類，直接返回
Dubbo自帶的RpcException，直接返回
其他的異常，會被封裝為RuntimeException返回
解決方式
根據以上的分析，那么很顯然，自定義異常是被直接封裝為RuntimeException返回了，而且只帶了自定義異常的類名信息，丟失了別的細節。
那么我們想要自定義異常進行正常返回，那只有滿足這個FIlter所寫的上述條件。我們可以分析一下：
不繼承RuntimeException，以檢查時異常拋出。不推薦，正常的業務異常應該是運行時異常。
在接口方法上要寫上throws BusinessException，如下：
public interface DemoService{
DemoUser getUserInfo(Long userID) throws BusinessException;
}
復制代碼
不推薦，不符合接口設計原則，且這樣是把運行時異常作為檢查時異常處理。
把自定義異常類和接口放在同一個包目錄下。不推薦，畢竟這樣相當于綁定了異常類的目錄，耦合性變高。
改包名，以“java.”或者“javax.”來開頭。不推薦，違反了類命名原則。
繼承Dubbo的RpcException。RpcException也是繼承了RuntimeException，因此能夠以RuntimeException的方式進行處理。不推薦，相當于自定義異常屬于Dubbo的RpcException，這在程序設計上不合理。
我們發現，想要滿足Dubbo的過濾器直接返回異常的條件，我們就必須做出一些違反程序設計的操作，如果一定要從這些方法中選擇一種的話，相對來說，自定義異常類和接口放在同一目錄下，以及繼承RpcException是對于程序侵入性更小的方式。
其他解決方式
參考 這篇文章，提供了兩種解決方式：
1.在配置文件中配置如下，效果是：關閉ExceptionFIlter，使所有異常繞過該過濾器直接返回。不推薦，Dubbo既然設置了這個異常過濾類，一定是出于安全和功能上的考慮，直接禁用可能會引發別的問題。
dubbo:
provider:
filter: -exception
復制代碼
2.修改Dubbo源文件ExceptionFilter，使其遇到BusinessException也能直接返回。不推薦，相當于定制了本地的Dubbo包，是一個后續很容易被人忽略的大坑。
總結
Dubbo在處理自定義異常時，會直接返回RuntimeException，且抹去自定義異常的所有細節，導致無法處理。
本文寫下的時候，Dubbo版本為2.7.3，該問題還沒有非常完美的解決方案，相對來說，把自定義異常和接口類放在同一目錄下是侵入性最小的方案。
總結
以上是生活随笔為你收集整理的dubbo全局异常处理_详解Dubbo无法处理自定义异常及解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： exists的用法 python_Pyt
- 下一篇： c++ sort 从大到小排序_算法的艺