什么是.NET中的ApplicationException？
为了抛出exception，我通常使用内置的exception类，例如ArgumentNullException和NotSupportedException 。 但是，有时我需要使用自定义exception，在这种情况下我写：
class SlippedOnABananaException : Exception { } class ChokedOnAnAppleException : Exception { }
等等。 然后我抛出并在我的代码中捕获这些。 但是今天我遇到了ApplicationException类 – 我应该使用它吗？ 这是为了什么？
有很多有效的相同的exception类与不同的名字（我通常不需要任何单独的function）似乎效率低下。 但是我不喜欢捕获一个generics的ApplicationException并且不得不使用额外的代码来确定错误是什么。
ApplicationException应该适合我的代码？
根据msdn的言论 ：
用户应用程序（而不是公共语言运行时）会抛出从ApplicationException类派生的自定义exception。 ApplicationException类区分应用程序定义的exception和系统定义的exception。
如果您正在devise需要创build自己exception的应用程序，则build议您从Exception类派生自定义exception。 最初认为自定义exception应该从ApplicationException类派生; 然而在实践中，这并没有被发现增加显着的价值。 有关更多信息，请参阅处理exception的最佳实践。
从Exception派生它们。 另外，只要是有保证的，我不会为您的案例创build新的例外。 如果遇到框架中已经存在exception的情况，请使用该框架，否则请自行开发。
简短的答案是：无处。
这是过去的遗留问题，微软希望开发人员从ApplicationExceptioninheritance所有的自定义exception。 不久之后，他们改变了主意，并build议自定义exception应该从基类Exception类派生。 请参阅在MSDN上处理exception的最佳实践 。
其中一个更广泛传播的原因是来自于Jeffery Richter在框架devise指南中的一个提示 ：
System.ApplicationException是一个不应该成为.NET Framework的一部分的类。 最初的想法是从SystemException派生的类将指示从CLR（或系统）本身抛出的exception，而非CLRexception将从ApplicationException派生。 但是，很多exception类并没有遵循这种模式。 例如， TargetInvocationException （由CLR引发）是从ApplicationException派生的。 所以， ApplicationException类失去了所有的意义。 从这个基类派生的原因是允许一些代码更高的调用堆栈捕捉基类。 捕获所有的应用程序exception已经不再可能了。
所以你有它。 执行摘要是ApplicationException不是有害的 ，只是没用 。
在最初的devise中，在.NET 1.0中，计划框架本身将抛出SystemException并派生出来; 而用户应用程序 – 将抛出ApplicationException并派生。
但后来，在.NET 2.0中，这一点被抛弃了。
从而导出Exception 。
