例外狀況和效能
注意
此內容是由 Pearson Education, Inc. 授權轉載自架構設計指導方針：可重複使用 .NET 程式庫的慣例、慣用語和模式，第 2 版。 該版於 2008 年出版，該書自那以後已於第三版進行了全面修訂。 此頁面上的某些資訊可能已過期。
例外狀況的其中一個常見考量是，如果例外狀況用於例行失敗的程式碼，實作的效能將無法接受。 此顧慮是有效的。 當成員擲回例外狀況時，其效能可能會變慢。 不過，在嚴格遵循不允許使用錯誤碼的例外狀況指導方針的同時，也有可能達到良好效能。 本節所述的兩種模式會建議執行此操作的方式。
❌ 請勿使用錯誤碼，因為擔心例外狀況可能會對效能造成負面影響。
若要改善效能，您可以使用 Tester-Doer 模式或 Try-Parse 模式，如下兩節所述。
Tester-Doer 模式
有時候，將成員分成兩個，即可改善例外狀況擲回成員的效能。 讓我們看看 ICollection<T> 介面的 Add 方法。
ICollection<int> numbers = ...
numbers.Add(1);
如果集合是唯讀，則會擲回方法 Add。 在預期方法呼叫經常失敗的案例中，這可能會是效能問題。 減輕問題的其中一種方式是先測試集合是否可寫入，然後再嘗試新增值。
ICollection<int> numbers = ...
...
if (!numbers.IsReadOnly)
{
numbers.Add(1);
}
用來測試條件的成員 (在我們的範例中是屬性 IsReadOnly)，稱為測試人員。 用來執行可能擲回作業的成員，Add 方法在我們的範例中稱為 doer。
✔️ 請考慮在常見案例中擲回例外狀況的成員 Tester-Doer 模式，以避免與例外狀況相關的效能問題。
Try-Parse 模式
對於非常區分效能的 API，應該使用比上一節所述 Tester-Doer 模式更快速的模式。 模式會呼叫以調整成員名稱，讓定義完善的測試案例成為成員語意的一部分。 例如，DateTime 定義在剖析字串失敗時擲回例外狀況的 Parse 方法。 其也會定義嘗試剖析的對應 TryParse 方法，但如果剖析失敗，則會傳回 false，並使用 out 參數傳回成功剖析的結果。
public struct DateTime
{
public static DateTime Parse(string dateTime)
{
...
}
public static bool TryParse(string dateTime, out DateTime result)
{
...
}
}
使用此模式時，請務必以嚴格的詞彙定義 try 函式。 如果成員因為定義完善嘗試以外的任何原因而失敗，該成員仍必須擲回對應的例外狀況。
✔️ 請考慮在常見案例中擲回例外狀況的成員 Try-Parse 模式，以避免與例外狀況相關的效能問題。
✔️ 請針對實作此模式的方法使用前置詞 "Try" 和布林值傳回類型。
✔️ 請使用 Try-Parse 模式，為每個成員提供例外狀況擲回成員。
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 節錄。