見過很多人在進行異常處理的時候，直接一個 e.printStackTrace（） 就完成了，這是一種非常粗陋的做法，首先會導(dǎo)致應(yīng)用日志的大量錯誤信息，而很多時候你都不知道這些錯誤信息因何發(fā)生；再者，反應(yīng)到用戶端將直接導(dǎo)致用戶無法獲取操作的結(jié)果以及失敗的原因。

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

不用使用異常來管理業(yè)務(wù)邏輯，應(yīng)該使用條件語句。如果一個控制邏輯可通過 if-else 語句來簡單完成的，那就不用使用異常，因為異常會降低代碼的可讀性和性能，例如一些 null 的判斷邏輯、除0的控制等等；

異常的名字必須清晰而且有具體的意思，表示異常發(fā)生的問題，例如 FileNotFoundException 就很清晰直觀

當方法判斷出錯該返回時應(yīng)該拋出異常，而不是返回一些錯誤值，因為錯誤值難以理解而且不夠直觀，例如拋出 FileNotFoundException 異常，而不是返回 -1 或者 -2 之類的錯誤值。

應(yīng)該捕獲指定的異常，而不是 catch（Exception e） 了事，這對性能、代碼的可讀性以及諸多方面都有好處

Null 的判斷邏輯并不是一成不變的，當方法允許返回 null 的時候使用 if-else 控制邏輯，否則就拋出 NullPointerException

盡量不要二次拋出異常，如果非得這么做的話，拋出同一個異常示例，而不是重新構(gòu)建一個異常對象，這對性能是有幫助的，而且外層調(diào)用者可獲取真實的異常信息

定義你自己的異常類層次，例如 UserException 和 SystemException 分別代表用戶級別的異常信息和系統(tǒng)級別的異常信息，而其他的異常在這兩個基類上進行擴展

明確的使用不同的異常類型：

Fatal： System crash states.

Error： Lack of requirement.

Warn： Not an error but error probability.

Info： Info for user.

Debug： Info for developer.

不要僅僅捕獲異常而不做任何處理，不便于將來維護

不要多次重復(fù)記錄同一個異常，這可以讓我們清晰的了解異常發(fā)生的位置

請使用 finally 來釋放一些打開的資源，例如打開的文件、數(shù)據(jù)庫連接等等

大部分情況下不建議在循環(huán)中進行異常處理，應(yīng)該在循環(huán)外對異常進行捕獲處理

異常的粒度很重要，應(yīng)該為一個基本操作定義一個 try-catch 塊，不要為了簡便，將幾百行代碼放到一個 try-catch 塊中

為你的異常生成足夠的文檔說明，至少是 JavaDoc

為每個異常消息定義一個數(shù)值，這對好的文檔來說是非常重要的。