Springboot項目中異常攔截設計與處理

背景：

項目運行過程中會出現各種各樣的問題，常見的有以下幾種情況：

1. 業務流程分析疏漏，對業務流程的反向操作、邊界分析設計不充分

2. 調用外部服務、調用外部系統出現的超時、錯誤、返回值與預期不符

3. 外部資源連通性問題，db等服務器出現的網絡抖動或宕機
   
   

無論是分析設計、開發、測試、線上都需要能夠准確定位問題並制定解決方案。

目的：

• 規范化異常的處理過程，避免異常被吞和到處都在捕獲異常的情況

• 准確的反饋異常信息，為定位問題提供依據

• 通用性異常全局處理，降低業務開發關注度 

• 對異常情況進行預警，以便能夠及時響應

一、異常規划

1. 業務類異常

造成業務流程不能正確執行的行為，常見的幾種：

• 輸入必填驗證

• 業務狀態約束校驗

• 權限驗證

• 調用外部服務返回數據不符合預期

這類異常需要給調用方返回明確的異常描述信息，一般情況下和代碼無關，無需調整編碼

注：是業務完整性的一部分，需提前分析

2. 系統類異常

• 服務調用異常： 超時、中斷、接口異常（非200請求）

• 第三方異常 ：db\redis\消息隊列 連接失敗等
  
  

注：通常與業務流程無關，與第三方系統有關，不能簡單的通過調整代碼解決

3. 通用異常

編碼不嚴謹、數據異常造成的問題，不可預測

舉例：參數類型不匹配、空指針、數組越界

二、異常攔截

在springboot中全局異常攔截處理已知的有下面2種方案：

方案1：@ControllerAdvice、實現ErrorController

      注：利用springboot自帶的攔截機制，只需要定義出處理的策略，沒有破壞springboot的約定

方案2：繼承AbstractHandlerExceptionResolver，完全自定義處理策略

      注：使用spring中最底層的類，打破了springboot的約定，能夠攔截到所有異常

 

三、方案實踐

 筆者基於方案一進行實踐。

1. 異常攔截時序圖

 

 

2. RrcRestAdvice實現代碼

2. RrcExpHandler實現代碼

注意：基於RestControllerAdvice的異常攔截只能捕獲請求達controller之后的程序異常，所以需要實現ErrorController處理之前的異常。

 

總結：

推薦基於springboot中@ControllerAdvice 和 ErrorController接口的約定，相對較符合springboot的約定。

其他可選方案：

繼承AbstractHandlerExceptionResolver

優點：可完全自定義處理策略。缺點：對框架約定破壞較為嚴重，自定義處理策略容易疏漏。

繼承HandlerInterceptorAdapter

理論上可以處理業務代碼拋出的異常，優缺點沒有進行過驗證。