見過很多人在進行異常處理的時候,直接一個 e.printStackTrace() 就完成了,這是一種非常粗陋的做法,首先會導緻應用日志的大量錯誤資訊,而很多時候你都不知道這些錯誤資訊因何發生;再者,反應到使用者端将直接導緻使用者無法擷取操作的結果以及失敗的原因。
以下 15 條異常處理的原則來自國外的部落格:
不用使用異常來管理業務邏輯,應該使用條件語句。如果一個控制邏輯可通過 if-else 語句來簡單完成的,那就不用使用異常,因為異常會降低代碼的可讀性和性能,例如一些 null 的判斷邏輯、除0的控制等等;
異常的名字必須清晰而且有具體的意思,表示異常發生的問題,例如 FileNotFoundException 就很清晰直覺
當方法判斷出錯該傳回時應該抛出異常,而不是傳回一些錯誤值,因為錯誤值難以了解而且不夠直覺,例如抛出 FileNotFoundException 異常,而不是傳回 -1 或者 -2 之類的錯誤值。
應該捕獲指定的異常,而不是 catch(Exception e) 了事,這對性能、代碼的可讀性以及諸多方面都有好處
Null 的判斷邏輯并不是一成不變的,當方法允許傳回 null 的時候使用 if-else 控制邏輯,否則就抛出 NullPointerException
盡量不要二次抛出異常,如果非得這麼做的話,抛出同一個
二手遊戲買賣平台異常示例,而不是重新建構一個異常對象,這對性能是有幫助的,而且外層調用者可擷取真實的異常資訊
定義你自己的異常類層次,例如 UserException 和 SystemException 分别代表使用者級别的異常資訊和系統級别的異常資訊,而其他的異常在這兩個基類上進行擴充
明确的使用不同的異常類型:
Fatal: System crash states.
Error: Lack of requirement.
Warn: Not an error but error probability.
Info: Info for user.
Debug: Info for developer.
不要僅僅捕獲異常而不做任何處理,不便于将來維護
不要多次重複記錄同一個異常,這可以讓我們清晰的了解異常發生的位置
請使用 finally 來釋放一些打開的資源,例如打開的檔案、資料庫連接配接等等
大部分情況下不建議在循環中進行異常處理,應該在循環外對異常進行捕獲處理
異常的粒度很重要,應該為一個基本操作定義一個 try-catch 塊,不要為了簡便,将幾百行代碼放到一個 try-catch 塊中
為你的異常生成足夠的文檔說明,至少是 JavaDoc
為每個異常消息定義一個數值,這對好的文檔來說是非常重要的。