什么时候在 C++ 中使用 exit() 与异常比较好？答案

【问题标题】：When is it better to use exit() vs exceptions in c++?什么时候在 C++ 中使用 exit() 与异常比较好？
【发布时间】：2020-01-28 18:35:53
【问题描述】：

我正在编写一个程序，根据输入值，代码将终止。这让我想到了实现这一点的最佳方法。我可以很容易地举出两个例子：

if (bad_value) {
    clean_up();
    exit(1);
}

类似的东西

try
    myFunc();
catch myException {
    clean_up();
    exit(1);
}

int myFunc() {
    if (badValue) throw myException;
    ...
}

第一个代码块看起来更干净，所以我想知道你为什么要使用异常？我想这真的是c 与c++ 的战斗。

【问题讨论】：

我会四处走动，说永远不会。在编写操作系统时曾经有一条规则，即整个事物中应该只有一条 HALT 指令。恕我直言，与应用程序相同。
我曾经维护过一个由数千行代码组成的程序，以前的开发人员认为，如果可以访问整个程序，则将链表链接到 exit 是个好主意的界限。因此，从最终用户的角度来看，应用程序只会随机关闭。弄清楚这并不好玩。
Why is using exit() considered bad?

【解决方案1】：

如果您正在编写应用程序代码，调用exit() 很好，但如果您正在编写库代码，那就不好了，因为exit() 强制整个应用程序终止，而库代码可能不是这样重要，应用程序宁愿继续。

注意你应该调用exit(EXIT_FAILURE) 告诉调用进程你的程序失败了。如果你抛出异常而不捕获它，那也足够了。

【讨论】：

【解决方案2】：

你是对的，这在很大程度上是 C style 与 C++ 风格的问题。

传递通过/失败标志的 C 习惯用法意味着您必须在可能发生的每个地方显式检查错误。如果该标志需要进一步向上传递调用堆栈，则每个函数都必须允许它。它很快就会变得笨拙。

调用exit 意味着底层代码正在就如何处理错误做出不可撤销的决定。通常这是不合适的。例如，如果您无法打开文件，也许您可以发出一条消息向用户表明这一点，然后在没有它的情况下运行。

【讨论】：

【解决方案3】：

您不应使用exit()。为了避免调用所有的析构函数，你应该使用std::quick_exit()。

应在代码的顶层处理所有异常，以免忘记日志记录或某些恢复过程。

【讨论】：

【解决方案4】：

exit() 适用于小程序。对于较大的程序，它有几个问题。首先，并非所有错误都应该终止程序——通常它可以恢复。

第二个问题：即使你想终止，也很难编写一个单独的clean_up() 函数来处理分配给程序各个部分的所有资源。这就是 C++ 中的 RAII 的用途。 exit() 与 RAII 不兼容，因为它不调用析构函数，全局或静态对象除外。

第三个问题：在错误检测的时候，你往往无法构造出对最终用户有意义的错误信息，但是当捕获到异常时却可以构造出这样的错误信息。

通常，两难境地是不同的：异常的替代方法是使用返回码来指示错误。异常和返回码之间存在多重权衡，数百篇文章专门讨论这个主题。这个答案太大了，无法分析。

【讨论】：

我认为@JohnZwinck 的部分答案应该放在这里：“如果你正在编写应用程序代码，调用 exit() 很好，但如果你正在编写库代码，那就不好了，因为当库代码故障可能不是那么重要并且应用程序宁愿继续时，exit() 会强制整个应用程序终止。”