例外のスロー

このセクションで説明する例外スローガイドラインでは、実行エラーの意味を適切に定義する必要があります。 実行エラーは、メンバーが行うように設計されたもの (メンバー名が意味するもの) を実行できない場合に発生します。 たとえば、 OpenFile メソッドが開いているファイル ハンドルを呼び出し元に返すことができない場合、実行エラーと見なされます。

ほとんどの開発者は、ゼロによる除算や null 参照などの使用エラーに例外を使用する作業に慣れ始めてきました。 フレームワークでは、実行エラーを含むすべてのエラー条件に例外が使用されます。

❌ エラー コードを返さないでください。

例外は、フレームワークでエラーを報告する主な手段です。

✔️ DO は、例外をスローして実行エラーを報告します。

✔️ コードでそれ以上実行しても安全でない状況が発生した場合は、例外をスローするのではなく、 System.Environment.FailFast (.NET Framework 2.0 機能) を呼び出してプロセスを終了することを検討してください。

❌ 可能であれば、通常の制御フローに例外を使用しないでください。

競合状態の可能性があるシステム障害や操作を除き、フレームワーク デザイナーは、ユーザーが例外をスローしないコードを記述できるように API を設計する必要があります。 たとえば、ユーザーが例外をスローしないコードを記述できるように、メンバーを呼び出す前に前提条件を確認する方法を提供できます。

別のメンバーの前提条件を確認するために使用されるメンバーは、多くの場合、テスターと呼ばれ、実際に作業を行うメンバーは doer と呼ばれます。

Tester-Doer パターンで許容できないパフォーマンス オーバーヘッドが発生する場合があります。 このような場合は、いわゆる Try-Parse パターンを考慮する必要があります (詳細については 、例外とパフォーマンス を参照してください)。

✔️ 例外をスローした場合のパフォーマンスへの影響を考慮してください。 1 秒あたり 100 を超えるスロー レートは、ほとんどのアプリケーションのパフォーマンスに大きく影響する可能性があります。

✔️ (システム障害ではなく) メンバー コントラクトの違反が原因でパブリックに呼び出し可能なメンバーによってスローされるすべての例外を文書化し、コントラクトの一部として扱います。

コントラクトの一部である例外は、あるバージョンから次のバージョンに変更しないでください (つまり、例外の種類を変更しないでください。また、新しい例外を追加しないでください)。

❌ 何らかのオプションに基づいてスローまたはスローできないパブリック メンバーを持つ必要はありません。

❌ 戻り値または out パラメーターとして例外を返すパブリック メンバーを含めないでください。

パブリック API から例外をスローするのではなく返すと、例外ベースのエラー報告の利点の多くが損なわれます。

✔️ 例外ビルダーメソッドを使用することを検討してください。

異なる場所から同じ例外をスローするのが一般的です。 コードの肥大化を回避するには、例外を作成し、そのプロパティを初期化するヘルパー メソッドを使用します。

また、例外をスローするメンバーはインライン化されません。 ビルダー内で throw ステートメントを移動すると、メンバーをインライン化できる場合があります。

❌ 例外フィルター ブロックから例外をスローしないでください。

例外フィルターで例外が発生すると、CLR によって例外がキャッチされ、フィルターから false が返されます。 この動作は、明示的に false を実行して返すフィルターとは区別できないため、デバッグが非常に困難です。

❌ finally ブロックから例外を明示的にスローしないようにします。 スローするメソッドを呼び出した結果として暗黙的にスローされる例外は許容されます。

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

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

こちらも参照ください

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