JAVA SpringBoot 設計應用程序異常體系思路

設計應用程序異常體系

在系統設計初期考慮應用程序的潛在問題是十分必要的，有效利用異常的特色，能夠知足應用的正確性或者健壯性等非功能性需求。

1. 異常設計方法

. 在架構設計中規定讓錯誤處理更偏向於健壯性仍是正確性 . 肯定應用程序的安全區域邊界 . 在架構設計中規定一組特定的異常處理技術 . 對穿越安全區域邊界的數據進行合法性校驗，並當數據非法的時候作出敏銳的反應 . 用斷言來講明編程假定，其中包括了前條件和後條件 . 規定合適的錯誤處理規模

2. 安全邊界

圖像界面，命令行界面，實時數據採集，外部文件，其餘外部對象(假定此處的數據是骯髒且不可信的) ----- 數據驗證類(這些類負債清理數據，它們構成了安全邊界) ---- 內部類1-你（這些類能夠假定數據都是乾淨且可信的） 讓軟件的某些部分處理 」不乾淨的「數據，而讓另一部分處理」乾淨的「數據，便可讓大部分代碼無須再負擔錯誤檢查數據的職責 安全邊界的使用使斷言和錯誤處理有了清晰的區分，安全邊界的外部程序使用錯誤處理技術，安全邊界內部創建斷言技術，傳進來的數據應該在安全邊界的時候已經被清理過了。

3. 異常處理技術

. 儘量去處理異常,recommended . 聲明異常，把異常傳給方法的調用者 . 記錄異常和相關信息 log . 使用默認值或替換數據 (限於數據不敏感系統) use default . 異常轉譯 exception translation . 忽略問題 ignore . 重試 retry . 恢復,enable again . rollback . shutdown system

4. 合法性校驗

檢查全部來源於外部的數據的值，網絡，文件，用戶，外部接口等。 . 數值，確保接受範圍之類 . 字符串：確保長度 . ID: 確保驗證合乎用途 . 溢出數據，注入的SQL命令，注入的HTML代碼，以及傳遞給系統調用的數據 . 檢查有害輸入數據代碼，緩衝區溢出，SQL注入，HTML注入，整數溢出，其餘惡性輸入數據 . 出錯消息中是否避免出校攻擊者攻入系統所需的消息(日誌脫敏)。

5. 斷言的應用

斷言對於大型的複雜性程序或者可靠性要求極高的程序來講尤爲有用 用錯誤處理代碼來處理預期會發生的狀況，用斷言來處理毫不應該發生的情況， 不該該使用斷言來測試瑣細問題，或可輕易修改的錯誤狀況 不該使用斷言來檢查public方法的輸入參數 能夠用斷言表達內部不定式，控制流不定式，初始條件，鎖狀態條件，結束條件，類不定式 若是發生異常狀況觸發了斷言，那麼要採起的措施不只僅是對錯誤作出恰當的反應了，而是應該修改程序的源代碼並從新編譯，而後發佈軟件的新版本。 用斷言來註解 precondition和postconditions, 是契約設計的一部分。 precondition assertion: 調用代碼要承擔的責任 postcondition assertion: 被調用方要承擔的責任

6. 可維護性設計原理（ 關鍵 業務的異常控制梳理流程）

面向對象+有效異常處理 = 可維護性設計 開始時候定義系統關鍵（！important）業務流程的行爲模型，可定義一個用例模型 識別業務操做或用例(UML) -> 完善業務操做，定義粒度更小的行爲(活動圖) -> 識別關鍵故障場景或操做風險 -> 肯定操做或方法中的潛在故障點 -> 肯定故障點的處理策略 識別關鍵故障場景或操做風險：操做，風險，評估級別 肯定操做或方法中的潛在故障點： 利用OO流程分解方法+順序圖 肯定故障點的處理策略 評估代碼，組件，API或架構風險和弱點的過程稱爲故障模式分析。 併入軟件設計，都要深刻了解與語言特性和API相關的風險。 注意：該技術只使用與程序中的主要問題，旨在識別全局影響的關鍵風險區域，否者會陷入設計鎖和流程當中。

7. Application 錯誤日誌的跟蹤和記錄

Log Spec AC . Choose MDC or NDC . add a filter to inject fileds(x-trace-id) to MDC . resttemplate inject fileds(x-trace-id, vin,...) . json format . log pattern ToKnow https://opentracing.io/ focus on trace project http://reactivex.io/ mutiple thread

. 話題討論

是否使用異常

產生異常和未產生異常的性能的較大差異，這就是說，應該遵循最佳編程實踐，沒必要再有效代碼和性能間折中，解決異常的基本規則是成立的，在處理產生異常的代碼時，原來的優先級保持不變。 把代碼放在try-catch塊反而阻止了JVM實現原本要執行的某些特定的優化 儘可能避免拋出異常 若是條件容許就處理異常 若是條件不容許就聲明異常

受查異常與非受查異常

服務可能會發生異常，但願調用者進行處理，就要拋出受查異常，受查異經常使用於控制業務邏輯 偶然異常，不是必然發生，也不須要調用者顯示的經過異常來判斷業務流程操做什麼的，就可使用非受查異常了 避免沒必要要的使用被檢查異常，雖然檢查異常大大提升了可靠性，然而過度的使用被檢查的異常會使API用起來很是不方便，把被受查異常轉變爲非受查異常的一種技術是分紅兩個方法，一個返回boolean,表面是否調用

異常的傳播

不用能異常來推卸責任，若是某種的錯誤狀況能夠在局部處理，那就應該在局部處理它，不要把原來能夠在局部處理掉的錯誤當成一個未被捕獲的異常拋出去。 避免在構造函數和析構函數裏拋出異常，否則異常處理的規則立刻就會變得複雜。 高層的實現應該捕獲低層的異常，同時拋出一個按照高層抽象進行解釋的異常，這種作法被稱爲異常轉譯(exception translation) 避免使用一個空的catch塊，忽略異常

異常日誌的記錄

對與不是特別重要的異常，不容許記錄日誌後又拋出異常，由於這樣會屢次記錄日誌，只容許記錄一次，低層日誌記錄錯誤參數，和結果，由系統高層異常處理器來記錄異常棧。

關於健壯性和正確性的討論

健壯性：不斷嘗試採起某些措施，以保證軟件能夠持續的運做下去，哪怕有時作出一些不夠準確的結果。 正確性：永遠不返回不許確的結果，不返回結果也比返回不正確的好

. 參考書籍：

《Robust Java中文版-Java異常處理、測試與調試》 《代碼大全2》 《Effective Java, 2nd Edition》 《agile java》 《重構，改善既有代碼的設計》 《測試驅動開發》 《Java編程思想第四版》 《rationa.統一開發過程》 《企業應用架構模式》 《敏捷軟件開發原則-模式與實踐》