例外狀況和效能
注意
此內容是由 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 節錄。