.NETのApplicationExceptionとは何ですか？
例外をスローするには、通常、組み込みの例外クラスを使用します。 ArgumentNullExceptionおよびNotSupportedException。ただし、カスタム例外を使用する必要がある場合があり、その場合は次のように記述します。
class SlippedOnABananaException : Exception { }
class ChokedOnAnAppleException : Exception { }
等々。次に、これらをコードにスローしてキャッチします。しかし、今日私はApplicationExceptionクラスに出会いました-代わりにそれを使うべきですか？何のために？
効果的に同一の例外クラスを異なる名前で多数持つことは非効率的と思われます（通常、個々の機能は必要ありません）。しかし、一般的なApplicationExceptionをキャッチし、エラーが何であるかを判断するために追加のコードを使用する必要があるという考えは嫌いです。
ApplicationExceptionは私のコードのどこに適合するべきですか？
Msdnの 備考 によると：
共通言語ランタイムではなくユーザーアプリケーションは、ApplicationExceptionクラスから派生したカスタム例外をスローします。 ApplicationExceptionクラスは、アプリケーションで定義された例外とシステムで定義された例外を区別します。
独自の例外を作成する必要があるアプリケーションを設計している場合、Exceptionクラスからカスタム例外を派生することをお勧めします。もともと、カスタム例外はApplicationExceptionクラスから派生するものと考えられていました。ただし、実際には、これが大きな価値をもたらすことは確認されていません。詳細については、例外処理のベストプラクティスを参照してください。
Exceptionから派生させます。また、保証されている限り、ケースの新しい例外を作成しても問題は発生しません。フレームワークにすでに例外があるケースが発生した場合は、それを使用します。それ以外の場合は、独自にロールします。
簡単な答えは：どこにもありません。
これは、Microsoftが開発者がApplicationExceptionからすべてのカスタム例外を継承することを意図した過去の遺物です。その後すぐに、彼らは気が変わって、カスタム例外はベースのExceptionクラスから派生するべきであるとアドバイスしました。 MSDNの 例外処理のベストプラクティス を参照してください。
これが広く普及している理由の1つは、 Framework Design Guidelines のJeffery Richterからの抜粋です。
System.ApplicationExceptionは、.NET Frameworkの一部であってはならないクラスです。元のアイデアは、SystemExceptionから派生したクラスはCLR（またはシステム）自体からスローされた例外を示し、非CLR例外はApplicationException。ただし、多くの例外クラスはこのパターンに従っていませんでした。たとえば、TargetInvocationException（CLRによってスローされます）は、ApplicationException。そのため、ApplicationExceptionクラスはすべての意味を失いました。この基本クラスから派生する理由は、基本クラスをキャッチするために、呼び出しスタックの上位のコードを許可するためです。すべてのアプリケーション例外をキャッチすることはできなくなりました。
だからあなたはそれを持っています。エグゼクティブサマリーは、ApplicationExceptionはharmfulではなく、単にuselessであるということです。
.NET 1.0の初期設計では、フレームワーク自体がSystemExceptionをスローして派生するように計画されていました。ユーザーアプリケーション中-ApplicationExceptionと派生をスローします。
しかし、後に.NET 2.0で削除されました。
したがって、Exceptionから派生します。