我理解将ApplicationException引入异常层次结构is retrospectively seen作为冗余移动。
同样，我理解没有理由直接从SystemException派生应用程序异常，并且Exception通常应该用于此目的。我可以想象从ArgumentException或IOException派生可能是一个好主意的情况，特别是在实现围绕这些设计/记录的预先存在的接口时。但是，直接从应用程序代码中的SystemException派生在我看来只是一个非常令人困惑的等同于从Exception派生，部分原因是我不知道SystemException试图表示什么。 （今天。不是历史。）
MSDN说：“用作系统异常命名空间的基类。...提供此类作为区分系统异常和应用程序异常的方法。”什么是循环定义。该类用作区分从它派生的类型和不是从它派生的类型的方法。
源于应用程序代码和系统代码的异常之间的整个历史区别似乎已经过时，特别是在依赖注入方案中，其中catch子句或记录的约定早在抛出点之前存在;因此，有大量编写良好的应用程序代码会抛出从SystemException派生的异常。
我是否正确地假设SystemException的存在理由是否曾因ApplicationException的消亡而消失？具体来说，如果这种类型突然从继承层次结构及其子类直接从Exception派生而消失，那么常见的常用编码技术是否会丢失？
答案 0 :(得分：1)
最初的意图显然是将异常划分为系统中发生的异常和应用程序中发生的异常。这种区别并未证明是非常有用的，因为这些例外通常不会有不同的处理方式。毕竟，所有异常都是由于应用程序所做的事情而发生的，系统不会自行处理，只是自己抛出异常。
当ApplicationException或多或少变得过时时，SystemException也是如此，但是有一些异常从类中继承，因此删除它们将是一个重大改变。可能有一些实际上使用它们的应用程序，因此最好将它们留在原地而不是冒一些应用程序停止工作的风险。
根据异常抛出的位置对异常进行分类对于错误处理并不是非常有用，如果您根据异常处理方式进行分析可能会更有用。例如，您可能需要异常基类来处理可以通过重复该过程解决的错误，以及无法从中恢复的错误。实际上，这可以在错误处理中用于以不同方式处理异常。