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

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

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

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

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

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

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

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

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

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

Fatal： System crash states.

Error： Lack of requirement.

Warn： Not an error but error probability.

Info： Info for user.

Debug： Info for developer.

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

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

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

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

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

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

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