擲回例外狀況
注意
此內容是由 Pearson Education, Inc. 授權轉載自架構設計指導方針：可重複使用 .NET 程式庫的慣例、慣用語和模式，第 2 版。 該版於 2008 年出版，該書自那以後已於第三版進行了全面修訂。 此頁面上的某些資訊可能已過期。
本節所述的例外狀況擲回指導方針，需要準確定義執行失敗的意思。 每當成員無法執行其設計目的 (如成員名稱所示) 時，就會發生執行失敗。 例如，如果 OpenFile 方法無法將開啟檔案控制代碼傳回給呼叫端，則會被視為執行失敗。
大部分的開發人員都熟悉透過例外狀況處理使用方式錯誤，例如除以零或 Null 參考。 在 Framework 中，例外狀況會用於所有錯誤狀況，包括執行錯誤。
❌ 請勿傳回錯誤碼。
例外狀況是報告架構中錯誤的主要方法。
✔️ 請擲回例外狀況來報告執行失敗。
✔️ 當程式碼遇到繼續執行不安全的情況時，請考慮呼叫 System.Environment.FailFast (.NET Framework 2.0 功能) 來終止程序，而不是擲回例外狀況。
❌ 請盡量不要對一般控制流程使用例外狀況。
除了具有潛在競爭條件的系統失敗和作業之外，架構設計人員應該設計 API，讓使用者可以撰寫不會擲回例外狀況的程式碼。 例如，您可以提供一個在呼叫成員之前檢查前置條件的方法，協助使用者撰寫不會擲回例外狀況的程式碼。
用來檢查另一個成員前置條件的成員通常稱為測試者 (Tester)，而實際執行工作的成員稱為執行者 (Doer)。
Tester-Doer 模式有時會造成無法接受的額外效能負荷。 在這種情況下，應該考慮所謂的 Try-Parse 模式 (請參閱例外狀況和效能以取得詳細資訊)。
✔️ 請考慮擲回例外狀況的效能影響。 每秒 100 次以上的擲回速率可能會明顯影響大部分應用程式的效能。
✔️ 請記錄公開可呼叫成員因違反成員合約 (而不是系統失敗) 而擲回的所有例外狀況，並將這些例外狀況視為合約的一部分。
屬於合約內容的例外狀況不應從一個版本變更為下一個版本 (換句話說，例外狀況類型不應該變更，且不應該新增例外狀況)。
❌ 請勿使用可根據某些選項擲回或無法擲回的公用成員。
❌ 請勿使用將例外狀況做為傳回值或 out 參數的公用成員。
若從公用 API 傳回例外狀況，而不是擲回例外狀況，將導致基於例外狀況的錯誤報表無法發揮效果。
✔️ 請考慮使用例外狀況建立器方法。
從不同的地方擲回相同的例外狀況很常見。 若要避免程式碼膨脹，請使用協助程式方法來建立例外狀況，並初始化其屬性。
此外，擲回例外狀況的成員不會內嵌。 在建立器內移動 throw 陳述式可能會允許成員進行內嵌。
❌ 請勿從例外狀況篩選區塊擲回例外狀況。
當例外狀況篩選引發例外狀況時，CLR 會攔截例外狀況，而篩選會傳回 false。 此行為無法與執行和明確傳回 false 的篩選進行區分，因此很難偵錯。
❌ 請避免從 finally 區塊明確擲回例外狀況。 由呼叫擲回方法所產生的隱含擲回例外狀況可以接受。
Portions © 2005, 2009 Microsoft Corporation. 著作權所有，並保留一切權利。
獲 Pearson Education, Inc. 的授權再版，從 Krzysztof Cwalina 和 Brad Abrams 撰寫，並在 2008 年 10 月 22 日由 Addison-Wesley Professional 出版，作為 Microsoft Windows Development Series 一部份的 Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries, 2nd Edition 節錄。