詳解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，該問題尚未很是完美的解決方案，相對來講，把自定義異常和接口類放在同一目錄下是侵入性最小的方案。