格拉布斯準則異常數據

讓我們回顧一些基本的異常設計準則，這些準則從“對象設計：角色，職責和協作”中進行了總結（Rebecca Wirfs-Brock和Alan McKean，Addison-Wesley，2003年）。

不要嘗試處理編碼錯誤。

除非在錯誤情況下要求您的軟件采取特殊措施，否則不要花很多時間設計它來檢測編程錯誤并從中恢復。 對于超出范圍的數組索引，除以零錯誤或任何其他編程錯誤，最好的策略是快速失敗（并留出可用于解決問題的審計線索）。

避免聲明很多異常類。

僅當您期望對代碼進行某種處理時，才根據例外類型創建新的例外類。 以我的經驗，這種情況很少，并且Java API中提供的異常類可以達到目的。 每當您提高抽象級別時，就將低級異常重鑄為高級別異常。

不要讓實現細節作為異常從方法調用中泄漏出來。

否則，您的用戶可能會認為您的軟件已損壞。 當低級異常滲透到高級處理程序時，幾乎沒有上下文可以幫助處理程序做出明智的決定或報告可追溯到任何明顯原因的條件。 每當您跨越抽象邊界重播異常時，可使異常處理程序在調用鏈中位于較高的位置，以做出更明智的決策。 如果要在重鑄問題時包含問題跟蹤，則始終可以創建鏈接的異常。 鏈接的異常提供了附加的上下文，并保留了對原始較低級別異常的引用。 您可以重復鏈接異常。

提供上下文以及異常。

在異常處理中最重要的是有助于創建明智響應的信息。 異常類保存信息。 除了默認情況下提供的基本堆棧跟蹤信息之外，您還可以將它們設計為包含其他信息。 您可能包括引發異常的參數值，特定的錯誤文本或對計劃恢復有用的詳細信息。

盡可能處理與問題接近的異常。

作為第一道防線，請考慮初始請求者。 如果呼叫者知道足夠的信息來執行糾正措施，則可以當場糾正情況。 如果您在遠離源的地方傳播異常，則可能很難跟蹤源。 通常，遠離問題的對象無法做出有意義的決策。

僅將異常用于表示緊急情況。

不應引發異常以指示正常的分支條件，這些條件會改變調用代碼中的流程。 例如，查找操作可能返回零，一個或多個對象，因此在這種情況下，我不會引發異常。 相反，我將設計自己的find（）方法以返回空對象或空集合。 另一方面，斷開數據庫連接確實是緊急情況。 無法按計劃繼續進行任何操作。

不要重復拋出相同的異常。

盡管在引發異常之前不花費任何費用，但經常引發異常的程序運行得更慢。

參考：來自我們的JCG合作伙伴 Sanjeev Kumar的“異常處理準則/最佳實踐”，來自Architect's Diary博客。

翻譯自: https://www.javacodegeeks.com/2012/04/exception-handling-guidelines-best.html

格拉布斯準則異常數據

總結

以上是生活随笔為你收集整理的格拉布斯准则异常数据_异常处理准则和最佳实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。