例外とパフォーマンス

例外に関連する一般的な懸念事項の 1 つは、定期的に失敗するコードに例外が使用されている場合、実装のパフォーマンスが許容できないことです。 これはもっともな心配です。 メンバーが例外をスローすると、パフォーマンスが桁違いに遅くなる可能性があります。 ただし、エラー コードの使用を禁止する例外ガイドラインに厳密に従いながら、優れたパフォーマンスを実現できます。 このセクションで説明する 2 つのパターンは、これを行う方法を示しています。

❌ 例外がパフォーマンスに悪影響を与える可能性があるため、エラー コードを使用しないでください。

パフォーマンスを向上させるために、次の 2 つのセクションで説明する Tester-Doer パターンまたは Try-Parse パターンを使用できます。

Tester-Doer パターン

例外をスローするメンバーのパフォーマンスが、メンバーを 2 つに分割することで向上する場合があります。 ICollection<T> インターフェイスのAddメソッドを見てみましょう。

ICollection<int> numbers = ...
numbers.Add(1);

このメソッド Add コレクションが読み取り専用の場合にスローされます。 これは、メソッド呼び出しが頻繁に失敗することが予想されるシナリオでは、パフォーマンスの問題になる可能性があります。 この問題を軽減する方法の 1 つは、値を追加する前にコレクションが書き込み可能かどうかをテストすることです。

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 以外の理由でメンバーが失敗した場合でも、メンバーは対応する例外をスローする必要があります。

✔️ 例外に関連するパフォーマンスの問題を回避するために、一般的なシナリオで例外をスローする可能性があるメンバーの Try-Parse パターンを検討してください。

✔️ このパターンを実装するメソッドには、プレフィックス "Try" と Boolean の戻り値の型を使用してください。

✔️ Try-Parse パターンを使用して、各メンバーに例外スローメンバーを指定します。

Portions © 2005, 2009 Microsoft Corporation. 無断転載を禁じます。

フレームワーク設計ガイドライン:再利用可能な .NET ライブラリの規則、イディオム、パターン、Krzysztof Cwalina および Brad Abrams による第 2 版は、2008 年 10 月 22 日に Microsoft Windows 開発シリーズの一部として Addison-Wesley Professional によって公開されました。

こちらも参照ください

• フレームワークの設計ガイドライン
• 例外のデザインのガイドライン