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

不要嘗試處理編碼錯誤。

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

避免聲明很多異常類。

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

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

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

提供上下文以及異常。

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

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

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

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

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

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

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

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