例外狀況和效能

備註

此內容經Pearson Education, Inc.授權從架構設計指導方針：可重複使用 .NET 程式庫的慣例、習慣用語與範式 (第2版)轉載。 該版於2008年出版，該書自那以後已於 第三版全面修訂。 此頁面的某些資訊可能已過期。

與例外狀況相關的一個常見考慮是，如果例外狀況用於經常失敗的程序代碼，則實作的效能將無法接受。 此顧慮是有效的。 當成員擲回例外狀況時，其效能可能會變得極其緩慢。 不過，在嚴格遵循不允許使用錯誤碼的例外狀況指導方針的同時，也有可能達到良好的效能。 本節所述的兩種模式會建議執行這項作的方法。

❌ 請勿使用錯誤碼，因為擔心例外狀況可能會影響效能。

若要改善效能，可以使用 Tester-Doer 模式或 Try-Parse 模式，如下兩節所述。

Tester-Doer 樣式

有時候，藉由將成員分成兩個，即可改善例外狀況擲回成員的效能。 讓我們看看 Add 介面的 ICollection<T> 方法。

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」 和 Boolean 傳回類型。

✔️ DO 提供一個會拋出異常的成員，使用 Try-Parse 模式為每個成員提供。

© 2005年、2009年Microsoft公司部分。 保留所有權利。

經 Pearson Education, Inc. 許可重新刊登自 Krzysztof Cwalina 和 Brad Abrams 所著的 架構設計指導方針: 可重複使用的 .NET 程式庫慣例、慣用語和模式，第 2 版，2008 年 10 月 22 日由 Addison-Wesley Professional 發行，作為 Microsoft Windows 開發系列的一部分。

另請參閱

• 架構設計指導方針
• 例外狀況的設計方針