前言

在業務邏輯中，通常使用兩種方式處理異常：

• 返回錯誤碼：優點是性能更好，但是不宜維護。
• 拋出異常：可以使得代碼更清晰，可讀性更好，更符合面向對象。

選擇哪種需要根據場景而定，不管如何選擇，只要團隊達成共識，統一規范就可以。

下面介紹一下我使用的處理異常的方式。

自定義異常

創建一個業務異?；?BaseException extends RuntimeException ，為其添加兩個屬性：code 和 message ，并添加一些常用的構造方法。

其中， **code **的作用是儲存錯誤碼，在返回前臺時將錯誤碼返回給用戶。

拋出異常：

錯誤碼管理

上面的自定義異?？雌饋砗芎唵?，但是不夠優雅和簡單。怎么將錯誤碼和錯誤信息管理起來，是我們接下來要解決的問題。

我使用了 Enum ，先創建一個接口，其中包含兩個方法：

• toCode()：將枚舉值轉為 int 錯誤碼，默認已實現；
• getMsg()：獲取枚舉中的異常信息。

下面創建一個枚舉類，實現上面的接口：

觀察上面的錯誤碼枚舉類，我們發現，枚舉值為 字母+錯誤碼 ，屬性 msg 為錯誤信息。

這樣將錯誤碼和異常信息統一管理起來之后，拋出異常的代碼就可優化為：

然而這樣依然不夠優雅，代碼量比之前還要長。要是能夠只傳枚舉值一個參數就好了，那么我們繼續優化。

創建一個異常類 BusinessException extends BaseException （創建一個子類，用來接收枚舉值），如下：

這樣我們就可以優雅的拋出 BusinessException 了：

如果想要保留原異常信息，還可以使用：

以上就是對異常處理的封裝，使用時，只需要在每個業務模塊中新建一個異常枚舉類，用來統一管理異常；需要時，在代碼中拋出 BusinessException 即可。

統一異常處理

最后，我們再使用 @ControllerAdvice 和 @ExceptionHandler 注解做一下統一異常處理，它的作用是：

• 將業務異常打印到日志中
• 將系統異常封裝為 BaseException 進行返回，同樣打印日志；
• 這里也可以做其他操作，比如短信提醒等。

代碼如下：