異常處理的 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. 為每個異常消息定義一個數值，這對好的文檔來說是非常重要的。
</ol>

你有其他的補充嗎？請不吝賜教。