C++异常所带来的问题

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

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

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

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
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 语言开发的库不会使用异常,如 curlzlog 等,但需要留意有些 C 语言库可能会使用 exit 和 abort 函数,我觉得使用这两个函数比使用异常更可怕,异常导致程序崩溃至少有迹可循,而这两个函数退出程序时,通常很难排查定位。

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

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

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