SystemException 是多余的吗？

Question

我知道将ApplicationException 引入异常层次结构is retrospectively seen 是多余的举动。

同样，我知道没有理由直接从SystemException 派生应用程序异常，并且Exception 通常应该用于此目的。我可以很好地想象从ArgumentException 或IOException 派生可能是一个好主意的情况，尤其是在实现围绕这些设计/记录的预先存在的接口时。但是，在应用程序代码中直接从SystemException 派生在我看来与从Exception 派生一样非常令人困惑，部分原因是我不知道SystemException 试图代表什么。 （今天。历史上没有。）

MSDN 说：“作为系统异常命名空间的基类。...提供这个类是为了区分系统异常和应用程序异常。”多么循环的定义.类用作区分从它派生的类型和不是从它派生的类型的一种方式。

在我看来，源自应用程序代码和系统代码的异常之间的整个历史区别似乎已经过时，尤其是在 catch 子句或文档化约定早在抛出点之前就存在的依赖注入场景中；所以有大量编写良好的应用程序代码会抛出源自SystemException 的异常。

如果有一个人随着ApplicationException 的消亡而消失，我是否正确地假设SystemException 的存在理由？具体来说，如果这种类型突然从继承层次结构及其直接派生自Exception 的子类中消失，是否会丢失任何常用的可靠编码技术？

Answer 1

最初的意图显然是将异常分为发生在系统中的异常和发生在应用程序中的异常。这种区别并没有被证明是非常有用的，因为这些异常通常不会以不同的方式处理。毕竟，所有异常的发生都是因为应用程序所做的事情，系统不会四处走动，只是自己抛出异常。

当ApplicationException 或多或少地过时时，SystemException 也或多或少地过时了，但是有许多从类继承的异常，因此删除它们将是一个重大变化。可能有一些应用程序实际上在使用它们，因此最好将它们留在原处，而不是冒着某些应用程序停止工作的风险。

根据异常的抛出位置对异常进行分类对于错误处理不是很有用，如果基于异常的处理方式可能会更有用。例如，您可能需要异常基类来处理可以通过重复该过程来解决的错误，以及无法从中恢复的错误。这实际上可以用于错误处理以不同方式处理异常。