是否从 ApplicationException 派生？
Derive from ApplicationException or not?
我对何时使用 ApplicationException 感到困惑。页面上写着
Serves as the base class for application-defined exceptions.
并且在同一页面上有以下警告
You should derive custom exceptions from the Exception class rather than the ApplicationException class. You should not throw an ApplicationException exception in your code, and you should not catch an ApplicationException exception unless you intend to re-throw the original exception.
所以它应该作为应用程序定义的异常的基础 class，但它不应该从中派生，也不应该被捕获。不幸的是，该警告没有说明任何进一步的推理。
在我们的应用程序中，我们想要的是捕获所有应用程序定义的异常，并将它们与 .net 本身的异常区别对待。因此，我们捕获了一个常见的异常，所有应用程序定义的异常都从中派生。
所以不要做
catch(AppCustomException ex) { ... }
catch(AnotherAppCustomException ex) { ... }
catch(YetAnotherAppCustomException ex) { ... }
我们有
catch(BaseCustomException ex) { ... } //All app custom exceptions derive from this type
我认为最好将 ApplicationException 作为所有自定义应用程序定义的异常的基础，而不是本例中的 BaseCustomException。
一位同事争辩说，由于 MSDN 上的规定，我们不能将 ApplicationException 用于这种常见的基本异常类型。特别是，它不应该派生自，也不应该在不重新传播时被捕获。我们不会重新抛出这些异常，这是有原因的。
所以我现在很困惑。 ApplicationException 的真正目的是什么？
原生 .NET 库中的一大堆异常继承 ApplicationException。我没有证据来源，但据我了解，它旨在用于 .NET 库.
中应用程序定义的异常
万一事实并非如此，在为派生自 ApplicationException 的应用程序创建自定义异常时，您将面临的问题是您可能会捕获一大堆您没有的 .NET 异常不在乎，甚至无法处理。基本上，每个 catch 都需要进行检查以确保您从自己的应用程序而非 .NET 捕获异常。
在您发布 link 的文档页面中列出源自 ApplicationException 的异常。
Microsoft.JScript.BreakOutOfFinally
Microsoft.JScript.ContinueOutOfFinally
Microsoft.JScript.JScriptException
Microsoft.JScript.NoContextException
Microsoft.JScript.ReturnOutOfFinally
System.Reflection.InvalidFilterCriteriaException
System.Reflection.TargetException
System.Reflection.TargetInvocationException
System.Reflection.TargetParameterCountException
System.Threading.WaitHandleCannotBeOpenedException
这个列表甚至还不完整，因为还有其他列表：DataSourceSerializationException、AppConfigException、NameValidationException 和其他...
因此，无论何时抛出其中一个，它都会在您期待 您的代码 .
出现异常时命中您的 catch (ApplicationException exception)
我强烈建议继续使用您的自定义基础异常。
我对何时使用 ApplicationException 感到困惑。页面上写着
Serves as the base class for application-defined exceptions.
并且在同一页面上有以下警告
You should derive custom exceptions from the Exception class rather than the ApplicationException class. You should not throw an ApplicationException exception in your code, and you should not catch an ApplicationException exception unless you intend to re-throw the original exception.
所以它应该作为应用程序定义的异常的基础 class，但它不应该从中派生，也不应该被捕获。不幸的是，该警告没有说明任何进一步的推理。
在我们的应用程序中，我们想要的是捕获所有应用程序定义的异常，并将它们与 .net 本身的异常区别对待。因此，我们捕获了一个常见的异常，所有应用程序定义的异常都从中派生。
所以不要做
catch(AppCustomException ex) { ... }
catch(AnotherAppCustomException ex) { ... }
catch(YetAnotherAppCustomException ex) { ... }
我们有
catch(BaseCustomException ex) { ... } //All app custom exceptions derive from this type
我认为最好将 ApplicationException 作为所有自定义应用程序定义的异常的基础，而不是本例中的 BaseCustomException。
一位同事争辩说，由于 MSDN 上的规定，我们不能将 ApplicationException 用于这种常见的基本异常类型。特别是，它不应该派生自，也不应该在不重新传播时被捕获。我们不会重新抛出这些异常，这是有原因的。
所以我现在很困惑。 ApplicationException 的真正目的是什么？
原生 .NET 库中的一大堆异常继承 ApplicationException。我没有证据来源，但据我了解，它旨在用于 .NET 库.
万一事实并非如此，在为派生自 ApplicationException 的应用程序创建自定义异常时，您将面临的问题是您可能会捕获一大堆您没有的 .NET 异常不在乎，甚至无法处理。基本上，每个 catch 都需要进行检查以确保您从自己的应用程序而非 .NET 捕获异常。
在您发布 link 的文档页面中列出源自 ApplicationException 的异常。
Microsoft.JScript.BreakOutOfFinally
Microsoft.JScript.ContinueOutOfFinally
Microsoft.JScript.JScriptException
Microsoft.JScript.NoContextException
Microsoft.JScript.ReturnOutOfFinally
System.Reflection.InvalidFilterCriteriaException
System.Reflection.TargetException
System.Reflection.TargetInvocationException
System.Reflection.TargetParameterCountException
System.Threading.WaitHandleCannotBeOpenedException
这个列表甚至还不完整，因为还有其他列表：DataSourceSerializationException、AppConfigException、NameValidationException 和其他...
因此，无论何时抛出其中一个，它都会在您期待 您的代码 .
出现异常时命中您的catch (ApplicationException exception)
我强烈建议继续使用您的自定义基础异常。