異常處理的 15 個處理原則

見過不少人在進行異常處理的時候，直接一個 e.printStackTrace() 就完成了，這是一種很是粗陋的作法，首先會致使應用日誌的大量錯誤信息，而不少時候你都不知道這些錯誤信息因何發生；再者，反應到用戶端將直接致使用戶沒法獲取操做的結果以及失敗的緣由。

如下 15 條異常處理的原則來自國外的博客：

1. 不用使用異常來管理業務邏輯，應該使用條件語句。若是一個控制邏輯可經過 if-else 語句來簡單完成的，那就不用使用異常，由於異常會下降代碼的可讀性和性能，例如一些 null 的判斷邏輯、除0的控制等等；
   
   
2. 異常的名字必須清晰並且有具體的意思，表示異常發生的問題，例如 FileNotFoundException 就很清晰直觀
   
   
3. 當方法判斷出錯該返回時應該拋出異常，而不是返回一些錯誤值，由於錯誤值難以理解並且不夠直觀，例如拋出 FileNotFoundException 異常，而不是返回 -1 或者 -2 之類的錯誤值。
   
   
4. 應該捕獲指定的異常，而不是 catch(Exception e) 了事，這對性能、代碼的可讀性以及諸多方面都有好處
   
   
5. Null 的判斷邏輯並非一成不變的，當方法容許返回 null 的時候使用 if-else 控制邏輯，不然就拋出 NullPointerException
   
   
6. 儘可能不要二次拋出異常，若是非得這麼作的話，拋出同一個異常示例，而不是從新構建一個異常對象，這對性能是有幫助的，並且外層調用者可獲取真實的異常信息
   
   
7. 定義你本身的異常類層次，例如 UserException 和 SystemException 分別表明用戶級別的異常信息和系統級別的異常信息，而其餘的異常在這兩個基類上進行擴展
   
   
8. 明確的使用不一樣的異常類型：
   Fatal: System crash states.
   Error: Lack of requirement.
   Warn: Not an error but error probability.
   Info: Info for user.
   Debug: Info for developer.
   
   
9. 不要僅僅捕獲異常而不作任何處理，不便於未來維護
   
   
10. 不要屢次重複記錄同一個異常，這可讓咱們清晰的瞭解異常發生的位置
    
    
11. 請使用 finally 來釋放一些打開的資源，例如打開的文件、數據庫鏈接等等
    
    
12. 大部分狀況下不建議在循環中進行異常處理，應該在循環外對異常進行捕獲處理
    
    
13. 異常的粒度很重要，應該爲一個基本操做定義一個 try-catch 塊，不要爲了簡便，將幾百行代碼放到一個 try-catch 塊中
    
    
14. 爲你的異常生成足夠的文檔說明，至少是 JavaDoc
    
    
15. 爲每一個異常消息定義一個數值，這對好的文檔來講是很是重要的。