例外狀況和效能

注意

此內容是由 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 節錄。

另請參閱