Cpp异常处理机制

栈展开

面试官： 在 C++ 中，当我们使用 try...catch 块来处理异常时，有一个重要的过程叫做 “栈展开 (Stack Unwinding)”。

你能用自己的话，简单描述一下，当一个异常被 throw 出来之后，到它被某个 catch 块捕获之前，这个“栈展开”的过程具体发生了什么吗？特别是，对于那些在栈上创建的对象，会发生什么？

比如，请看下面这段代码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
#include <iostream>

// 一个简单的类，在构造和析构时会打印信息
struct RAII_Helper {
    int id;
    RAII_Helper(int i) : id(i) { std::cout << "RAII_Helper " << id << " constructed.\n"; }
    ~RAII_Helper() { std::cout << "RAII_Helper " << id << " destructed.\n"; }
};

void func_C() {
    RAII_Helper h3(3);
    std::cout << "Entering func_C, about to throw.\n";
    throw std::runtime_error("An error occurred in C!");
    std::cout << "This line in func_C is never reached.\n";
}

void func_B() {
    RAII_Helper h2(2);
    std::cout << "Entering func_B, calling C.\n";
    func_C();
    std::cout << "This line in func_B is never reached.\n";
}

void func_A() {
    RAII_Helper h1(1);
    std::cout << "Entering func_A, calling B.\n";
    try {
        func_B();
    }
    catch (const std::exception& e) {
        std::cout << "Caught exception in A: " << e.what() << "\n";
    }
    std::cout << "Exiting func_A.\n";
}

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

函数调用链是 main -> func_A -> func_B -> func_C。

func_A 创建了对象 h1。
func_B 创建了对象 h2。
func_C 创建了对象 h3，然后抛出 (throw) 了一个异常。
异常最终在 func_A 的 catch 块中被捕获。

我的问题是： 从 func_C 抛出异常，到 func_A 捕获异常，这个过程中，h1, h2, h3 这三个对象的析构函数，它们会被调用吗？如果会，调用的顺序是怎样的？这个过程就是所谓的栈展开 (Stack Unwinding)。请你描述一下。

回答：

h1, h2, h3 这三个对象的析构函数，都会被调用。它们的调用顺序是：h3 -> h2 -> h1，即后生成的变量，将先被销毁。这是由栈的“后进先出”特性 (LIFO) 决定的。
这是因为，当 throw 语句被执行时，程序会暂停正常流程，开始一个特殊的过程——寻找 catch 块。
如果在局部对象中找不到对应的 catch 块，那么程序会销毁局部对象，然后退出。

程序执行上面的函数，实际的输出：

RAII_Helper 1 constructed.
Entering func_A, calling B.
RAII_Helper 2 constructed.
Entering func_B, calling C.
RAII_Helper 3 constructed.
Entering func_C, about to throw.
RAII_Helper 3 destructed.
RAII_Helper 2 destructed.
Caught exception in A: An error occurred in C!
Exiting func_A.
RAII_Helper 1 destructed.

面试官 (总结与深化): 你说的非常对。

栈展开 (Stack Unwinding) 的过程，就是 C++ 异常处理机制的核心。当 func_C 中 throw 语句被执行时，程序会暂停正常执行流，开始一个特殊的“寻找 catch 块”的过程：

检查当前函数：首先，程序检查 func_C 内部是否有能处理这个异常的 try...catch 块。在这个例子里，没有。
销毁局部对象并退出：因为在 func_C 找不到 catch，程序决定退出 func_C。在退出之前，它会负责任地销毁所有在 func_C 作用域内已经成功构造的栈对象。所以，h3 的析构函数 ~RAII_Helper() 被调用。然后，func_C 的栈帧被销毁。
向上一层传播：程序回到 func_C 的调用点，也就是 func_B 内部。
重复过程：程序现在检查 func_B 内部是否有 try...catch。还是没有。
销毁并退出：程序决定退出 func_B。在退出前，它销毁了 func_B 的栈对象 h2。h2 的析构函数被调用。func_B 的栈帧被销毁。
再向上一层：程序回到 func_B 的调用点，也就是 func_A 的 try 块内部。
找到 catch 块：程序发现，func_B() 的调用是被一个 try 块包裹的，并且后面跟着一个能匹配 std::runtime_error 的 catch 块。
捕获异常：栈展开过程暂停。程序跳转到 catch 块内部开始执行。
正常流程恢复：catch 块执行完毕后，程序会继续执行 catch 块后面的代码（比如 Exiting func_A）。当 func_A 最终结束时，h1 作为 func_A 的局部变量，也会被正常地销毁。

核心结论：

C++ 的异常处理机制保证了，在栈展开的过程中，所有在栈上创建的对象的析构函数都会被正确调用。

这正是我们之前讨论的 RAII (Resource Acquisition Is Initialization) 思想能够安全工作的基础。即使发生异常，std::unique_ptr, std::vector, std::string 这些 RAII 类的析构函数也一定会被调用，从而保证它们管理的堆内存、文件句柄等资源不会泄漏。

你对栈展开的理解已经非常到位了。

`noexcept` 关键字

面试官 (引入 noexcept): 好的，既然我们知道了异常处理涉及到栈展开这个（可能比较复杂和耗时）的过程。在某些情况下，我们作为函数的设计者，可以向编译器做出一个承诺：“我保证，我的这个函数绝对不会抛出任何异常。”

C++11 引入了 noexcept 关键字，来让我们做出这个承诺。

1
2
void might_throw();
void will_not_throw() noexcept;

我的问题是： 将一个函数声明为 noexcept，主要会带来什么好处？特别是，它对编译器优化有什么帮助？

（提示：想想看，当编译器处理一个调用了可能抛出异常的函数的代码时，和处理一个调用了保证不抛出异常的函数的代码时，它需要生成的机器代码有什么不同？）

回答：

编译器在处理可能抛出异常的函数的代码时，需要随时考虑退出并销毁当前的函数栈，这让编译器需要编译更加复杂的机器码。
将一个函数声明为 noexcept，编译器就知道“这个函数不会 throw 任何的异常”。那么，编译器就不用考虑提前退出当前函数和销毁函数栈的问题，编译出的机器码更加简单。

面试官 (总结与深化): 你说的完全正确。我们来把这个过程再具体化一点。

当编译器编译一段调用了普通函数（可能会抛出异常）的代码时，它必须生成一些**“悲观”**的代码：

它需要在调用函数前后，保存现场（比如寄存器的状态）。
它需要准备好能够正确执行栈展开 (Stack Unwinding) 的代码路径。
这会增加代码体积，并且可能会阻止一些其他的编译优化（比如指令重排、内联等），因为编译器必须保守地假设异常随时可能发生。

而当你将一个函数声明为 noexcept 时，你等于给了编译器一个**“优化许可证”**：

编译器完全信任你的承诺。
在编译调用 noexcept 函数的代码时，它不需要生成任何用于处理栈展开的额外代码。
它可以更大胆地进行内联、指令重排等优化，因为它知道函数调用后，程序的执行流是可预测的，不会突然跳转到某个 catch 块。
最终生成的机器码会更小、更简单、执行效率也更高。

那么，如果我们违反了承诺呢？ 如果在 noexcept 函数内部，确实有一个异常被抛出，并且这个异常没有在函数内部被 catch 住，那么会发生什么？

程序不会进行栈展开。
取而代之的是，程序会立刻调用 std::terminate()，这通常会导致整个应用程序立即终止。

这是一种严厉的惩罚，它强调了 noexcept 是一个需要严格遵守的契约。

`nonexcept` 和移动语义的结合

面试官 (最终问题): 好的，你对 noexcept 的基本作用已经很清楚了。

在现代 C++ 中，noexcept 还有一个极其重要的作用，那就是和移动语义 (Move Semantics) 结合。

我们之前讨论过，STL 容器（比如 std::vector）在扩容时，会尝试移动 (move) 元素，而不是拷贝 (copy)，以提高性能。

但是，STL 容器在决定是否“可以”安全地使用移动操作时，会检查这个元素的移动构造函数是否被声明为 noexcept。

请问，为什么 std::vector 在扩容时，会如此关心元素的移动构造函数是不是 noexcept 的？

（提示：这和 STL 容器需要提供的异常安全保证 (Exception Safety Guarantee) 有关。如果在一半的元素被移动之后，其中一个元素的移动构造函数突然抛出了异常，vector 会处于一个什么样的可怕状态？）

回答：

如果在调用移动构造函数到一半时，突然抛出异常，那么程序会退出当前的栈，并销毁临时对象。
而移动构造函数是通过直接重新分配已有资源的方式来完成赋值，这意味着 vector 将损失已经移动的数据。
因此，程序需要确保这个移动构造的过程不会出现异常。

面试官 (解释与澄清): 你的回答已经非常接近问题的核心了！“vector 将损失已经移动的数据”，这正是关键所在。

我们来把这个“可怕的状态”描绘得更具体一些。

std::vector 在设计时，需要提供一个叫做 “强异常安全保证 (Strong Exception Safety Guarantee)”。这意味着：

如果一个操作（比如 push_back 导致的扩容）因为异常而失败了，那么 vector 的状态应该回滚到操作开始之前的状态，就好像什么都没发生过一样。

我们来模拟一下扩容过程： vector 需要把旧内存 old_buffer 里的 10 个元素，移动到新内存 new_buffer 里。

情况一：移动构造函数是 noexcept 的

vector 可以放心地、一个接一个地调用移动构造函数。
move(elem1), move(elem2), …, move(elem10)。
因为它知道这个过程绝对不会抛出异常，所以可以安全地完成所有元素的迁移。

情况二：移动构造函数不是 noexcept 的 (可能会抛出异常)

vector 面临一个两难的抉择。它开始移动：
1. move(elem1) -> 成功。old_buffer[0] 变成空壳。
2. move(elem2) -> 成功。old_buffer[1] 变成空壳。
3. …
4. move(elem5) -> 突然，这个移动构造函数 throw 了一个异常！
灾难发生了！
- 栈展开开始，扩容操作失败。
- 此时 vector 处于一个 “残缺” 的状态：
  - new_buffer 里有 4 个被成功移动过来的元素。
  - old_buffer 里，前 4 个元素已经成了“空壳”，后 6 个元素还是好的。
- 整个 vector 的数据既不在旧地方，也不在新地方，数据已经永久性地损坏了！它无法回滚到操作之前的状态。

vector 的解决方案： 为了保证“强异常安全”，std::vector 的实现会做一个聪明的检查：

“在扩容时，我需要把元素从旧内存搬到新内存。我先检查一下，这个元素的类型 T，它的移动构造函数是不是 noexcept 的？”
如果是 noexcept：“太棒了！我可以安全地使用移动，又快又好。”
如果不是 noexcept：“哦，这个移动操作有风险，可能会在半路抛异常，把我的数据搞乱。为了保证强异常安全，我不能冒这个险。我宁愿选择更慢、但绝对安全的方式——拷贝 (Copy)。”

因为拷贝构造函数通常只复制数据，如果失败了，原始数据还在，vector 可以安全地回滚。

结论： 将你自定义的类的移动构造函数和移动赋值运算符声明为 noexcept，是一个极其重要的性能优化。这等于是在告诉所有 STL 容器：“请放心大胆地对我使用移动操作吧，我保证不会出问题！” 否则，即使你提供了移动操作，vector 等容器也可能因为安全原因而不敢使用它，退化去使用拷贝。

总结

今天我们深入探讨了 C++ 的异常处理机制：

我们理解了栈展开如何保证 RAII 的实现。
学习了 noexcept 如何通过向编译器承诺“不抛出异常”来优化性能。
并最终揭示了 noexcept 在保证 std::vector 等容器能够安全、高效地使用移动语义中的关键作用。

你今天的表现非常出色，能通过引导，层层深入地理解这些复杂的底层机制。继续保持！

栈展开

noexcept 关键字

nonexcept 和移动语义的结合

总结

相关文章

`noexcept` 关键字

`nonexcept` 和移动语义的结合