为了抛出异常，我通常使用内置的异常类，例如ArgumentNullException和NotSupportedException。但是，有时我需要使用自定义异常，在这种情况下，我会写：

等等。然后我在代码中抛出并捕获这些。但今天我遇到了ApplicationException班——我应该用这个来代替吗？这是干什么用的？

有许多具有不同名称的有效相同异常类(我通常不需要任何单独的功能)似乎效率低下。但是我不喜欢捕获一个通用的ApplicationException，并且必须使用额外的代码来确定错误是什么。

ApplicationException应该在哪里适合我的代码？

简短的回答是：无处可去。

这是过去的遗留问题，微软打算让开发人员从applicationexception继承他们所有的自定义异常。不久之后，他们改变了主意，建议自定义异常应该从基本异常类派生。请参阅有关处理msdn上异常的最佳实践。

其中一个更广泛传播的原因来自杰弗里里克特在框架设计指南中的一个练习：

System.ApplicationException is a class that should not be part of the .NET Framework. The original idea was that classes derived from SystemException would indicate exceptions thrown from the CLR (or system) itself, whereas non-CLR exceptions would be derived from ApplicationException. However, a lot of exception classes didn't follow this pattern. For example, TargetInvocationException (which is thrown by the CLR) is derived from ApplicationException. So, the ApplicationException class lost all meaning. The reason to derive from this base class is to allow some code higher up the call stack to catch the base class. It was no longer possible to catch all application exceptions.

所以你有了它。执行摘要是applicationexception不是有害的，只是无用的。

根据msdn中的注释：

User applications, not the common language runtime, throw custom exceptions derived from the ApplicationException class. The ApplicationException class differentiates between exceptions defined by applications versus exceptions defined by the system.

If you are designing an application that needs to create its own exceptions, you are advised to derive custom exceptions from the Exception class. It was originally thought that custom exceptions should derive from the ApplicationException class; however in practice this has not been found to add significant value. For more information, see Best Practices for Handling Exceptions.

从Exception中得到它们。另外，我认为只要有必要，为您的案例创建新的例外不会有问题。如果遇到框架中已经存在异常的情况，请使用该异常，否则，请滚动自己的异常。

在最初的设计中，在.NET 1.0中，计划框架本身将抛出SystemException并派生；而用户应用程序将抛出ApplicationException并派生。

但后来，在.NET 2.0中，它被删除了。

由此衍生出Exception。