備註
此內容經Pearson Education, Inc.授權從架構設計指導方針：可重複使用 .NET 程式庫的慣例、習慣用語與範式 (第2版)轉載。 該版於2008年出版，該書自那以後已於 第三版全面修訂。 此頁面的某些資訊可能已過期。
本節所描述的拋出例外指導方針需要明確定義何為執行失敗。 每當成員無法執行其設計用途時，就會發生執行失敗（成員名稱所暗示的內容）。 例如，如果 OpenFile 方法無法將開啟的檔案句柄傳回給呼叫端，則會被視為執行失敗。
大部分的開發人員都對使用例外狀況感到自在，例如除以零或 Null 參考。 在 Framework 中，例外狀況會用於所有錯誤狀況，包括執行錯誤。
❌ 請勿傳回錯誤碼。
例外狀況是報告架構中錯誤的主要方法。
✔️ 請通過擲回例外來報告執行失敗。
✔️ 如果您的程式碼遇到不安全執行的情況，請考慮呼叫 System.Environment.FailFast（.NET Framework 2.0 功能）來終止進程，而不是擲回例外狀況。
❌ 如果可能的話，請勿對一般控制流程使用例外狀況。
除了系統故障和具有潛在競爭條件的操作之外，架構設計者應該設計 API，讓使用者可以撰寫不會擲回例外狀況的程式代碼。 例如，您可以在呼叫成員之前提供檢查前置條件的方法，讓使用者撰寫不會擲回例外狀況的程序代碼。
用來檢查另一個成員前置條件的成員通常稱為「測試者」，而實際執行工作的成員稱為「執行者」。
在某些情況下，Tester-Doer 模式可能會有無法接受的效能負荷。 在這種情況下，應該考慮所謂的 Try-Parse 模式（如需詳細資訊，請參閱 例外狀況和效能 ）。
請考慮拋出例外的效能影響。 每秒 100 次以上的擲回速率可能會明顯影響大部分應用程式的效能。
應記錄可公開呼叫的成員擲回的所有例外狀況，因為它們違反了成員合約（而非系統失敗），並將其視為合約的一部分。
屬於合約一部分的例外狀況不應從某個版本變更為下一個版本（亦即，不應該變更例外狀況類型，而且不應該加入新的例外狀況）。
❌ 請勿有公用成員，可以根據某些選項擲回或不擲回。
❌ 請勿有公用成員，以傳回例外狀況做為傳回值或 out 參數。
如果從公用 API 傳回例外狀況，而不是拋出例外狀況，會抵消例外狀況錯誤報告的許多優點。
✔️ 請考慮使用例外狀況產生器方法。
從不同位置擲出相同的例外狀況很常見。 若要避免程式代碼膨脹，請使用協助程式方法來建立例外狀況並初始化其屬性。
此外，拋出例外的成員不會被內嵌。 將 throw 語句移動到建構器中可能可以使成員被內嵌。
❌ 請勿從例外篩選區塊拋出異常。
當例外篩選器引發例外狀況時，CLR 會捕捉該例外狀況，篩選器會返回 false。 ** 這種行為與篩選條件執行後明確傳回 false 的情況難以區分，因此很難除錯。
❌ 避免從 finally 區塊明確拋出例外狀況。 從呼叫擲回的方法產生的隱含擲回例外狀況是可接受的。
© 2005年、2009年Microsoft公司部分。 保留所有權利。
經 Pearson Education, Inc. 許可重新刊登自 Krzysztof Cwalina 和 Brad Abrams 所著的 架構設計指導方針: 可重複使用的 .NET 程式庫慣例、慣用語和模式，第 2 版，2008 年 10 月 22 日由 Addison-Wesley Professional 發行，作為 Microsoft Windows 開發系列的一部分。