背景：

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

• 業務流程分析疏漏，對業務流程的反向操作、邊界分析設計不充分
• 調用外部服務、調用外部系統出現的超時、錯誤、返回值與預期不符
• 外部資源連通性問題，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

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

好了，以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，如果有疑問大家可以留言交流，謝謝大家對服務器之家的支持。

原文鏈接：http://www.cnblogs.com/yuhuashang-edward/p/10076217.html