.NETのApplicationExceptionとは何ですか？

例外をスローするには、通常、組み込みの例外クラスを使用します（例：ArgumentNullExceptionおよび）NotSupportedException。ただし、カスタム例外を使用する必要がある場合があり、その場合は次のように記述します。

class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }

等々。次に、これらをコードにスローしてキャッチします。しかし、今日私はApplicationExceptionクラスに出くわしました-代わりにそれを使うべきですか？何のために？

異なる名前の効果的に同一のExceptionクラスを多数持つことは非効率的に見えます（通常、個別の機能は必要ありません）。しかし、私はジェネリックをキャッチしApplicationException、エラーが何であるかを決定するために追加のコードを使用しなければならないという考えを嫌います。

ApplicationException私のコードはどこに合わせる必要がありますか？

msdn の発言によると：

共通言語ランタイムではなく、ユーザーアプリケーションがApplicationExceptionクラスから派生したカスタム例外をスローします。ApplicationExceptionクラスは、アプリケーションによって定義された例外とシステムによって定義された例外を区別します。

独自の例外を作成する必要があるアプリケーションを設計している場合は、Exceptionクラスからカスタム例外を派生させることをお勧めします。当初、カスタム例外はApplicationExceptionクラスから派生する必要があると考えられていました。ただし、実際には、これが重要な価値を追加することはありません。詳細については、「例外処理のベストプラクティス」を参照してください。

から派生しますException。また、保証されている限り、ケースの新しい例外の作成に問題はありません。フレームワークですでに例外が発生している場合は、それを使用してください。それ以外の場合は、独自にロールしてください。

簡単に言えば、どこにもありません。

これは、Microsoftが開発者にApplicationExceptionからすべてのカスタム例外を継承することを意図した過去の遺物です。その直後、彼らは考えを変え、カスタム例外は基本のExceptionクラスから派生するべきだとアドバイスしました。MSDNの例外処理のベストプラクティスを参照してください。

これがより広く流通する理由の1つは、フレームワーク設計ガイドラインの Jeffery Richterからの抜粋です。

System.ApplicationExceptionは、.NET Frameworkの一部であってはならないクラスです。もともとの考え方は、SystemExceptionから派生したクラスはCLR（またはシステム）自体からスローされた例外を示し、CLR以外の例外はApplicationExceptionから派生するというものでした。ただし、多くの例外クラスはこのパターンに従っていませんでした。たとえば、TargetInvocationException（CLRによってスローされます）はApplicationExceptionから派生します。そのため、ApplicationExceptionクラスはすべての意味を失いました。この基本クラスから派生する理由は、基本クラスをキャッチするために、呼び出しスタックの上位にあるコードを許可するためです。すべてのアプリケーション例外をキャッチすることができなくなりました。

だからあなたはそれを持っています。エグゼクティブサマリーは、ApplicationExceptionは有害ではなく、役に立たないということです。

最初の設計では、.NET 1.0では、フレームワーク自体がスローされSystemExceptionて派生することが計画されていました。一方、ユーザーアプリケーション-スローApplicationExceptionして派生します。

しかし、後に.NET 2.0では、それは削除されました。

したがって、から派生しExceptionます。