c++ - 为什么要保守地使用异常？

Question

我经常看到/听到人们说异常应该只很少使用，但从不解释原因。虽然这可能是真的，但基本原理通常是一个油嘴滑舌:“它被称为有原因的异常(exception)”，对我来说，这似乎是一种不应该被受人尊敬的程序员/工程师接受的解释。

有一系列问题可以使用异常来解决。 为什么将它们用于控制流是不明智的？对它们的使用方式异常保守背后的哲学是什么？语义？性能？复杂性？美学？公约？

我之前看过一些关于性能的分析，但在与某些系统相关而与其他系统无关的层面上。

同样，我不一定不同意它们应该在特殊情况下保存，但我想知道共识的基本原理是什么(如果存在这样的事情)。

Answer 1

主要的摩擦点是语义。许多开发人员滥用异常并捕获一切机会抛出它们。这个想法是在一些特殊情况下使用异常。例如，错误的用户输入不算作异常，因为您希望这会发生并为此做好准备。但是，如果您尝试创建一个文件并且磁盘上没有足够的空间，那么是的，这是一个明确的异常(exception)。

另一个问题是异常经常被抛出和吞下。开发人员使用这种技术来简单地“静默”程序并让它运行尽可能长的时间直到完全崩溃。这是非常错误的。如果你不处理异常，如果你没有通过释放一些资源来做出适当的 react ，如果你没有记录异常发生或至少没有通知用户，那么你就没有使用异常的含义。

直接回答你的问题。应该很少使用异常，因为异常情况很少见，而且异常昂贵。

很少见，因为您不希望每次按下按钮或每次输入格式错误时程序都会崩溃。比如说，数据库可能突然无法访问，可能没有足够的磁盘空间，您依赖的某些第三方服务离线，这一切都可能发生，但很少见，这些都是明显的异常(exception)情况。

昂贵，因为抛出异常会中断正常的程序流程。运行时将展开堆栈，直到找到可以处理异常的适当异常处理程序。它还将在整个过程中收集调用信息以传递给处理程序将接收的异常对象。这都是有代价的。

这并不是说使用异常就没有异常(exception)(微笑)。有时，如果您抛出异常而不是通过多层转发返回代码，则可以简化代码结构。作为一个简单的规则，如果您希望某个方法经常被调用并且在一半的时间里发现了一些“异常”情况，那么最好找到另一个解决方案。但是，如果您希望大部分时间都能正常运行，而这种“异常”情况只能在极少数情况下出现，那么抛出异常就可以了。

@Comments:如果可以使您的代码更简单、更容易，则绝对可以在一些不太异常(exception)的情况下使用异常。这个选项是开放的，但我想说它在实践中很少见。

Why is it unwise to use them for control flow?

因为异常会破坏正常的“控制流”。您引发异常并放弃程序的正常执行，这可能会导致对象处于不一致状态，并且某些开放资源未释放。当然，C# 有 using 语句，它可以确保即使从 using 主体抛出异常，对象也会被释放。但是让我们暂时从语言中抽象出来。假设框架不会为您处理对象。你手动完成。你有一些关于如何请求和释放资源和内存的系统。您在系统范围内达成一致，谁负责在什么情况下释放对象和资源。您有如何处理外部库的规则。如果程序遵循正常的操作流程，则效果很好。但是在执行过程中突然你抛出一个异常。一半的资源未被释放。一半还没有被要求。如果该操作现在是事务性的，它就会被破坏。您处理资源的规则将不起作用，因为那些负责释放资源的代码部分根本不会执行。如果其他人想使用这些资源，他们可能会发现它们处于不一致的状态并崩溃，因为他们无法预测这种特殊情况。

比如说，你想要一个方法 M() 调用方法 N() 来做一些工作并安排一些资源，然后将它返回给 M() ，后者将使用它然后处理它。很好。现在 N() 中出了点问题，它在 M() 中抛出了一个您没有预料到的异常，因此异常冒泡到顶部，直到它可能被某些方法 C() 捕获，而 C() 将不知道在深处发生了什么在 N() 中以及是否以及如何释放一些资源。

通过抛出异常，您可以创建一种方法，将您的程序带入许多难以预测、理解和处理的新的不可预测的中间状态。这有点类似于使用 GOTO。设计一个程序可以将其执行从一个位置随机跳转到另一个位置是非常困难的。它也很难维护和调试。当程序变得越来越复杂时，您只会失去对何时何地发生的事情的概览，而无法修复它。