問題描述

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，該問題還沒有非常完美的解決方案，相對來說，把自定義異常和介面類放在同一目錄下是侵入性最小的方案。