C++异常所带来的问题

当我们在代码中写下一行 throw 语句时，我们就此埋下了一个祸根，从此以后，在该函数调用链中，必须至少有一个调用者需要提供相应的异常捕获，否则一旦异常被抛出，程序就会异常终止。

例如，函数 f() 调用 g()，而 g() 又调用 h()，并且 h() 抛出一个异常，则 g() 和 f()中必须有一个提供了相应的异常捕获，否则程序会异常终止。

由于异常会使代码的执行流程从任意地方跳出，因此我们还需要付出大量的精力来编写正确的异常安全代码，例如使用 RAII（资源获取即初始化）来保证资源正确释放。

如下面的示例，虽然我们在函数 f() 中捕获了异常，避免了程序的异常终止，但异常却中断了函数 g() 的正常执行流程，导致对象 m 没有被正确释放，从而出现了资源泄露。这种情况可能还会变相地增加了程序的调试难度。

void h() {
    throw std::exception();
}

void g() {
    int* m = new int();
    h();
    delete m;
}

void f() {
    try {
        g();
    }
    catch (...) {
    }
}

int main()
{
    f();
    return 0;
}

启用异常还会在每个生成的二进制文件中添加额外的数据，从而增加编译时间（可能只是略微增加）并可能增加地址空间的使用。

异常的存在可能会导致开发人员滥用异常，在本不该（或不需要）抛出异常的地方抛出异常。例如，无效的用户输入就不应抛出异常。

即便我们捕获了异常，我们也很难从异常中恢复回来，因为我不能确定异常具体是从调用链的哪一步抛出的，也无法知晓每一步的实现逻辑，因此如果程序中使用了异常，我们除了做好必要的参数检查，尽量避免异常发生，在异常被抛出时，让程序自然的退出也是一个不错的选择。

能完全避免使用异常吗？

太难了，我们很难完全避免使用异常。

在 C++ 标准库（STL）中，大多数情况是通过抛出异常的形式来返回错误的，虽然我们可以使用诸如 EASTL 这样的库来替代 STL，但仍然很难避免程序使用的其他库不会使用 STL 以及抛出异常，比如常用的日志库 spldlog、boost库、rpclib库等都会抛出异常。

因此要完全的不使用异常，我们需要从头实现众多的基础组件，这是一个巨大的工作量。

折中的办法

虽然我们很难完全避免异常，但我们还是可以努力远离异常的。

下面是我的一点点建议：

可以使用 EASTL 替代 STL，或者仅使用 STL 中不抛出异常的模块。

在选择第三方库时，尽量选择不使用异常的库，通常 C 语言开发的库不会使用异常，如 curl、zlog 等，但需要留意有些 C 语言库可能会使用 exit 和 abort 函数，我觉得使用这两个函数比使用异常更可怕，异常导致程序崩溃至少有迹可循，而这两个函数退出程序时，通常很难排查定位。

保证自己编写的代码不主动抛出异常，例如函数通过返回值的形式返回错误，并且尽可能使用 C++ 17 中的[[nodiscard]]，强制调用者检查返回值。但应避免使用全局状态变量，如 Windows 的 LastError，因为这样会破坏函数调用的局部性。

构造函数也可能会失败，但我们不应使用异常来抛出错误。按照惯例，可以使用两步构造法，在构造函数中只做基本的、不会出错、不会抛出异常的操作或者直接使用空的构造函数，然后提供一个单独的 init 函数来进行初始化，并返回错误码。

异常捕获的粒度不宜太细，如果对每一行可能抛出异常的语句都进行异常捕获，这样会导致代码过于繁琐。如果粒度太粗，又会导致异常难于恢复，失去了捕获的意义。我们要做的是，在调用函数前，对参数进行充分地检查，尽量避免异常的发生，然后仅在关键代码位置进行异常捕获。

本文采用署名-非商业性使用-相同方式共享 4.0 国际许可协议，转载请注明出处。

C++异常之我所见

C++异常所带来的问题

能完全避免使用异常吗？

折中的办法