c++ - 什么时候可以通过捕获异常来真正解决问题？

Question

事情是这样的。关于异常，我不太明白，对我来说，它们似乎是一种几乎有效的构造，但不能干净地使用。

我有一个简单的问题。捕获异常何时成为解决问题根本原因的有用或必要组成部分？ IE。您什么时候能够编写代码来修复通过异常发出的问题？我正在寻找事实数据，或者您拥有的经验。

这就是我的意思。正常的程序确实可以工作。如果由于原因 X 无法完成某项工作，则负责执行该工作的函数将引发异常。但谁捕获异常呢？在我看来，您可能想要捕获异常有以下三个原因:

1. 你捕获它是因为你想改变它的类型并重新抛出它。 (当您将机械异常(例如 std::out_of_range)转换为业务异常(例如 could_not_complete_transaction)时，就会发生这种情况)
2. 您捕获它是因为您想在中止之前记录它，或者让用户知道该问题。
3. 你捕获它是因为你实际上知道如何解决问题。

我对第三点表示怀疑。我从来没有真正捕获过异常，知道如何解决它。当你得到一个 std::out_of_memory 时，你应该用它做什么？您不可能用操作系统来交换来获得更多内存。这不是你能解决的问题。不仅仅是 std::out_of_memory，还有一些业务类异常也会受到此影响。考虑一下潜在的 connection_error 异常:除了等待并稍后重试并希望它自行修复之外，您还能做什么来解决此问题？

现在，公平地说，我确实知道一种情况，其中代码确实捕获了异常并尝试解决问题。我知道某些 Win32 SEH 处理程序会捕获堆栈溢出异常，并尝试通过扩大线程堆栈的大小(如果可能)来解决问题。但是，这是可行的，因为 SEH 具有尝试恢复语义，而 C++ 异常没有这种语义(您无法在异常发生时恢复)。

问题的主要部分已经结束。但是，我还有另一个问题，但在我看来，这正是为什么没有使用 catch 子句来解决问题的原因:捕获异常的代码必须与抛出异常的代码结合在一起。因为，为了解决问题，它必须具有关于问题原因的特定领域知识。但是，当某些库记录“如果此函数失败，将引发 internal_error 异常”时，当我不知道该库内部如何工作时，我应该如何解决该问题？

PS:请注意，这不是“异常与错误代码”类型的问题；我很清楚错误代码作为一种错误处理机制很糟糕。他们实际上遇到了我已经解释过的异常问题。

Answer 1

我认为你的问题在于你将“解决问题”等同于“使程序继续正确运行”。这是思考异常或一般错误处理的错误方式。

任何类型的错误处理代码都不应该是程序可以在内部修复的代码。也就是说，由于编程错误，不应输入错误处理逻辑(如捕获异常)。

如果用户给你一个不存在的文件名，这不是一个编程错误；而是一个错误。这是一个用户错误。如果不返回用户并获取现有文件，您就无法“修复”该问题。但异常确实允许您撤消尝试执行的操作，将程序恢复到有效状态，然后向用户传达发生的情况。

invalid_connection 同样不是编程错误。与上述不同，这也不一定是用户错误。这是预期能够发生的事情，不同的程序将以不同的方式处理它。有些人会想再试一次。其他人会想要停止并让用户知道。

关键是，因为没有一种方法可以处理这种情况，所以图书馆无法做到这一点。必须将错误提供给库的调用者以确定该怎么做。

如果您有一个解析整数的函数，并且给定的文本不符合整数，那么该函数的工作就不是确定下一步要做什么。需要通知调用者他们提供的字符串格式错误，并且应该采取措施。

调用者需要处理错误。

您不会中止大多数程序，因为本应包含整数的文件实际上并不包含整数。但是您的解析函数确实需要将此事实传达给调用者，并且调用者确实需要处理这种可能性。

这就是“捕获异常”的用途。

现在，像 OOM 这样的意外环境条件就不同了。这通常不是外部代码的错误，但通常也不是编程错误。如果它是一个编程错误(即:内存泄漏)，那么在大多数情况下您都无法处理它。 P0709有一个完整的章节是关于程序能够普遍响应 OOM 的能力(或缺乏能力)。结果是，即使程序针对 OOM 异常进行了防御性编码，但当内存不足时，它们通常仍然会损坏。

特别是在处理操作系统时，在您实际使用它们之前不会将页面提交到内存中。