小編教您Springboot項目中異常攔截設計與處理
業務流程分析疏漏，對業務流程的反向操作、邊界分析設計不充分
調用外部服務、調用外部系統出現的超時、錯誤、返回值與預期不符
外部資源連通性問題，db等服務器出現的網絡抖動或宕機
無論是分析設計、開發、測試、線上都需要能夠準確定位問題並制定解決方案。
目的：
規範化異常的處理過程，避免異常被吞和到處都在捕獲異常的情況
準確的反饋異常信息，為定位問題提供依據
通用性異常全局處理，降低業務開發關註度
對異常情況進行預警，以便能夠及時響應
一、異常規劃
- 業務類異常
造成業務流程不能正確執行的行為，常見的幾種：
輸入必填驗證
業務狀態約束校驗
權限驗證
調用外部服務返回數據不符合預期
註：是業務完整性的一部分，需提前分析
- 系統類異常
服務調用異常： 超時、中斷、接口異常（非200請求）
第三方異常 ：db edis消息隊列 連接失敗等
註：通常與業務流程無關，與第三方系統有關，不能簡單的通過調整代碼解決
- 通用異常
編碼不嚴謹、數據異常造成的問題，不可預測
舉例：參數類型不匹配、空指針、數組越界
二、異常攔截
在springboot中全局異常攔截處理已知的有下面2種方案：
方案1：@ControllerAdvice、實現ErrorController
註：利用springboot自帶的攔截機制，只需要定義出處理的策略，沒有破壞springboot的約定
方案2：繼承AbstractHandlerExceptionResolver，完全自定義處理策略
註：使用spring中最底層的類，打破了springboot的約定，能夠攔截到所有異常
三、方案實踐
筆者基於方案一進行實踐。
-
異常攔截時序圖
- RrcRestAdvice實現代碼
- RrcExpHandler實現代碼
註意：基於RestControllerAdvice的異常攔截只能捕獲請求達controller之後的程序異常，所以需要實現ErrorController處理之前的異常。
總結：
推薦基於springboot中@ControllerAdvice 和 ErrorController接口的約定，相對較符合springboot的約定。
其他可選方案：
繼承AbstractHandlerExceptionResolver
優點：可完全自定義處理策略。缺點：對框架約定破壞較為嚴重，自定義處理策略容易疏漏。
繼承HandlerInterceptorAdapter
理論上可以處理業務代碼拋出的異常，優缺點沒有進行過驗證。
小編教您Springboot項目中異常攔截設計與處理