.net - .NET没有概念性(Fatal-)Error异常类型的设计原因？

Question

Closed. This question is opinion-based。它当前不接受答案。












想改善这个问题吗？更新问题，以便 editing this post用事实和引用来回答。

5年前关闭。



Improve this question





初步说明：

此问题无意于在.NET上抨击，也无意引发“致命异常”之类的讨论战争-Java的设计师 clearly thought there are ，. NET设计师要么以为是，否则就不知道了。 ，或者可能有另一个（技术上的）原因使异常层次结构保持现状。

我最感兴趣的是任何MS设计师是否都有设计文档或声明，为什么.NET层次结构就是今天的样子。大胆的猜测和猜测将得出错误的答案。内在的争论/示例为什么没有这样的东西（可分类的） Fatal Exception当然可以做出有效的答案，尽管我一定不同意它们。但是，与评论相反，我保证不会与任何内在的答案争论;-)另一类答案可能表明有证据表明Java的 Error类型分类是一个坏主意/实际上在Java中不起作用，从而隐式显示了.NET为什么不需要它。 :-)



在努力成为经验丰富的C＃程序员的过程中，我注意到 .NET exception hierarchy中一些我认为很奇怪的东西（*）：

所有引发类型的基类为 Exception（ well, basically anyway）。

具体来说，许多异常直接从 Exception派生而来的 categorization到 SystemException->等，似乎有点毫无意义。

例如，对我来说尤其奇怪的是，当 SEHException是-a ExternalExpection是-a SystemException时，它实际上似乎更像是一种崩溃和烧伤的错误。

虽然在Java方面没有过分的经验，但我发现Java在wrt方面与众不同。 Error type与“正常” Exception很有道理。当然可以争论细节，但是 .NET / C＃甚至不尝试这种方法似乎很奇怪。

C＃知名度的Eric Lippert有一个 nice piece on categorizing exceptions，我对此大为认同，这让我感到更加奇怪，为什么.NET甚至没有尝试为“致命异常”提供存储桶。



通过“致命异常”，我基本上暗示了利珀特先生描述的相同概念：


致命异常不是您的错，您无法阻止它们，并且您
无法理智地清除它们。 ...


注意：最重要的是，它们很可能（尤其是不是）您引发异常的操作错误。


...他们几乎总是会发生，因为
这个过程深陷疾病，即将被淘汰
苦难。内存不足，线程中止等等。绝对有
捕获这些毫无意义，因为您微不足道的用户代码无能为力
将解决问题。只要让您的“最终”障碍运行起来，并希望
最好的。 （或者，如果您真的很担心，请快速失败，不要让
最终块运行；在这一点上，它们可能会使情况变得更糟。
但这是另一天的话题。）


我将注意到，从技术上讲，某些致命异常与其他任何异常一样完全可以。您应该能够在适当的时间捕获它-只是对于99％的代码根本不适合处理这些。

以Lipperts先生为例：说我调用一个函数来打开一个文件，该文件可能引发各种异常。如果发现其中任何一个，我要做的就是报告打开文件失败的原因X，并继续进行适当的操作。但是，如果打开文件引发了ThreadAbortedException，则报告任何内容都没有意义，因为文件打开操作没有失败，但是某些代码中止了当前线程并在与假设的FileNotFoundException相同的情况下进行了处理。在绝大多数情况下都是有意义的。



评论者似乎认为，只有捕获站点才能真正判断某些东西是否“致命”，并且没有适当的事先分类，但是我强烈怀疑有一个很好的例外列表，其中99％的用户代码从不希望捕获：

拿 StackOverflowException（而且我敢肯定还有更多），它“只是”一个常规的SystemException，被认为是致命的：


在.NET Framework 1.0和1.1中，您可以捕获
StackOverflowException对象（例如，从无界恢复
递归）。从.NET Framework 2.0开始，您将无法
带有try / catch块的StackOverflowException对象，以及
默认情况下终止相应的进程。


请注意，我认为致命的异常不必立即终止应用程序（相反）。我要问的是，当设计人员显然确实认为某些异常比其他异常致命时，.NET框架为什么不尝试在异常的层次结构中表示“致命性”。



（*）“考虑相当奇怪”实际上意味着我个人，在时间连续体的这一点上，找到了.NET异常层次结构 totally botched。

最佳答案

首先让我说，对于StackOverflow来说，这不是一个特别好的问题。这不是关于实际代码的特定技术问题，而是寻求设计文档（一种非现场资源），或者寻求为何按原样设计特定类层次结构的理由。两者都不太适合SO。

也就是说，我可以在这里进行一些观察。

我认为这是一个合理的假设，所有参与的人都对SystemException和ApplicationException的存在感到遗憾。在当时，将异常分为两大类似乎是个好主意：由“系统”本身生成的异常，以及由系统用户创建的异常。但是实际上，这不是有用的区分，因为您对异常所做的事情就是捕获它们，并且在什么情况下您想要捕获（1）所有用户生成的异常或（2）所有系统生成的异常？没有任何情况出现。

这说明在特定情况下并不是设计上的失败-尽管可以肯定的是设计不是很好-而是在单继承OOP中，您只能在“继承枢轴”上获得一招通常被称为Microsoft，一个糟糕的决定可能会长期困扰您。

现在很容易地说，回顾过去，我们也许应该使用其他一些枢轴。您注意到在我的文章中我根据异常的捕获方式对异常进行了分类-致命异常没有被捕获，因为捕获异常对您没有好处，硬骨头异常没有被捕获，因为它们实际上是调试辅助工具，必须捕获令人讨厌的异常由于API设计不佳，必须捕获外部异常，因为它们表明世界与您所希望的有所不同。似乎有可能在此处进行更好的调整，其中异常类型指示它是否致命，并指示是否需要捕获它。当然，这不是唯一可能的枢纽，但似乎是可行的。可以设计一个静态分析器（在编译器或第三方工具中），以验证是否正确捕获了异常。

这似乎特别合理，因为.NET中当然有一些例外，这些例外实际上是超级双重错误。您可以捕获堆栈溢出或线程中止，但是系统会积极地重新抛出它们。如果以某种方式捕获到元数据中，那将是很好的。

作为语言设计者，尽管我会做进一步的回顾，要说的是，这里的根本问题是异常机制本身如果不被滥用就会过度工作。

例如，为什么我们需要致命异常才能成为异常？如果确实是某些异常是致命的情况，并且确实是在某些罕见但关键的情况下，即使由于致命异常而导致程序关闭，您也需要运行代码，那么该情况可能会上升到您希望语言中的语法捕获这些语义的级别。说一个try-fatality块，其中清除代码仅在致命错误的极少数情况下运行。也许这是一个好主意，也许不是，但是重点是，提出了一种在语言中放置功能来解决问题的想法，而不是将越来越多的语义叠加到似乎不太适合所有用途的机制上它被放置。

例如，为什么根本没有“骨头”异常？实际上存在一些异常例外，例如“不允许将此引用为null，您可以虚拟”或“您试图在关闭文件后写入文件，您可以虚拟”，这是唯一的例外，因为它们是以下方面的缺点第一种情况是类型系统，第二种情况是API设计。理想情况下，不会出现白痴，因为首先根本不可能用该语言来表示不良程序。可以将诸如代码合同之类的机制内置到该语言中，以帮助确保在编译时捕获“骨头”异常情况。再说一次，也许这是个好主意，但也许不是，但是重点是，有机会在语言设计级别解决此问题，而不是让异常承担这种负担，然后询问如何设计一个可以代表明显的头脑异常。

关于.net - .NET没有概念性(Fatal-)Error异常类型的设计原因？ ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27830217/

上一篇：php - Yii2:编写表单 Action 的正确方式

下一篇：ruby-on-rails-4 - Rails 4 - 带有 accepts_nested_attributes_for Controller 设置的嵌套表单？

相关文章：

python - 为什么 Python 决定不使用常量引用？

php - HipHop PHP 编译器的 C++ 输出是什么样的？

c# - 从 TableAdapter 中删除行？

c# - 如何克隆 FileStream 类型？

java - 如果文件不存在，如何使输出流创建文件？

java - 使用 Spring AOP 捕获异常后不返回值

swift - “ fatal error :在展开可选值时意外发现nil”是什么意思？

c# - 为什么必须在静态类中定义 C# 扩展方法？

.net - 简单的批量数据持久化框架

c# - 将 EF CodeFirst 基类转换为继承类(使用 table-per-type)

Answer 1

首先让我说，对于StackOverflow来说，这不是一个特别好的问题。这不是关于实际代码的特定技术问题，而是寻求设计文档（一种非现场资源），或者寻求为何按原样设计特定类层次结构的理由。两者都不太适合SO。

也就是说，我可以在这里进行一些观察。

我认为这是一个合理的假设，所有参与的人都对SystemException和ApplicationException的存在感到遗憾。在当时，将异常分为两大类似乎是个好主意：由“系统”本身生成的异常，以及由系统用户创建的异常。但是实际上，这不是有用的区分，因为您对异常所做的事情就是捕获它们，并且在什么情况下您想要捕获（1）所有用户生成的异常或（2）所有系统生成的异常？没有任何情况出现。

这说明在特定情况下并不是设计上的失败-尽管可以肯定的是设计不是很好-而是在单继承OOP中，您只能在“继承枢轴”上获得一招通常被称为Microsoft，一个糟糕的决定可能会长期困扰您。

现在很容易地说，回顾过去，我们也许应该使用其他一些枢轴。您注意到在我的文章中我根据异常的捕获方式对异常进行了分类-致命异常没有被捕获，因为捕获异常对您没有好处，硬骨头异常没有被捕获，因为它们实际上是调试辅助工具，必须捕获令人讨厌的异常由于API设计不佳，必须捕获外部异常，因为它们表明世界与您所希望的有所不同。似乎有可能在此处进行更好的调整，其中异常类型指示它是否致命，并指示是否需要捕获它。当然，这不是唯一可能的枢纽，但似乎是可行的。可以设计一个静态分析器（在编译器或第三方工具中），以验证是否正确捕获了异常。

这似乎特别合理，因为.NET中当然有一些例外，这些例外实际上是超级双重错误。您可以捕获堆栈溢出或线程中止，但是系统会积极地重新抛出它们。如果以某种方式捕获到元数据中，那将是很好的。

作为语言设计者，尽管我会做进一步的回顾，要说的是，这里的根本问题是异常机制本身如果不被滥用就会过度工作。

例如，为什么我们需要致命异常才能成为异常？如果确实是某些异常是致命的情况，并且确实是在某些罕见但关键的情况下，即使由于致命异常而导致程序关闭，您也需要运行代码，那么该情况可能会上升到您希望语言中的语法捕获这些语义的级别。说一个try-fatality块，其中清除代码仅在致命错误的极少数情况下运行。也许这是一个好主意，也许不是，但是重点是，提出了一种在语言中放置功能来解决问题的想法，而不是将越来越多的语义叠加到似乎不太适合所有用途的机制上它被放置。

例如，为什么根本没有“骨头”异常？实际上存在一些异常例外，例如“不允许将此引用为null，您可以虚拟”或“您试图在关闭文件后写入文件，您可以虚拟”，这是唯一的例外，因为它们是以下方面的缺点第一种情况是类型系统，第二种情况是API设计。理想情况下，不会出现白痴，因为首先根本不可能用该语言来表示不良程序。可以将诸如代码合同之类的机制内置到该语言中，以帮助确保在编译时捕获“骨头”异常情况。再说一次，也许这是个好主意，但也许不是，但是重点是，有机会在语言设计级别解决此问题，而不是让异常承担这种负担，然后询问如何设计一个可以代表明显的头脑异常。