C++ 异常机制深度解析：栈展开与控制流原理

底层至少发生两件事：

• 构造异常对象（包含类型信息 + 错误消息，通常在**'运行时'**分配/管理）
• 构造异常运行时入口（可以理解为把控制权交给异常处理系统）

注意：此刻开始，控制流不再沿着我们写的函数继续往下走

（2）寻找处理者：沿着调用栈'查表'，找到能接住它的 catch

异常运行时接管后，会做一件很关键的事：

从 throw 点出发，沿着调用栈向上查找：有没有在某一层存在匹配的 catch？

编译器在编译时会为每个函数生成异常相关的元数据（可理解为 异常表 / unwind 信息），**'运行时'**会根据这些信息判断：

• 当前栈帧是否处于某个 try 覆盖范围内
• 是否存在 catch(T) 能匹配这个异常类型（含继承、多态匹配）
• 如果匹配不到，就继续向更外层栈帧查找

如果一直找到 main 都没有匹配的 catch，**'运行时'**最终会走到 std::terminate()。

这一阶段的关键点是：

• 先'找落点'：确认最终会跳到哪个 catch
• 找到之前，程序并不会开始销毁过程

（3）回溯清理：从 throw 点到 catch 落点之间，逐栈帧清理

当'运行时'确定了'最终会被哪个 catch 接住' 之后，才开始真正的栈展开：

从 throw 所在的栈帧开始，一层层弹出栈帧，执行每层需要执行的清理代码。

编译器在编译时会为栈帧生成对应的清理逻辑，运行时会按顺序执行它们。

注：正常的函数作用域结束后，会执行编译器编译的析构指令，这是正常执行流；但异常执行流是走不到正常执行流的清理部分，所以编译器为异常执行流编译了特殊的清理逻辑（一种正常执行流被打断的补偿机制）

• 先析构当前作用域内已经构造完成的局部对象（RAII 资源在这里释放）
• 再离开该作用域
• 然后继续回溯到上一层调用者的栈帧

用一段代码感受：

struct A { ~A(){ std::cout << "~A\n"; } };
struct B { ~B(){ std::cout << "~B\n"; } };
void f() { A a; B b; throw std::runtime_error("x"); }
void g() { A a2; f(); }
int main() { try { g(); } catch (...) {} }

可以看到控制台输出：

(此处省略图片展示)

栈展开时析构发生的顺序是：

• f() 内：先 ~B 再 ~A（同一作用域：先构造先析构，和正常执行流的逻辑一样）
• 回到 g()：再析构 a2
• 最终回到 main 的 catch

（4）跳转进入 catch：控制流回到处理点

当 throw 点到 catch 点之前的栈帧都完成清理后：

• 栈已经回到 catch 所在的那一层
• '运行时把控制流移交给对应的 catch 块'
• 若是 catch(const std::exception &e)，还会绑定到异常对象

到此为止，异常处理完成一次闭环：

找落点 -> 清理路径 -> 跳到 catch

什么是'运行时'？

先说定义：

运行时（runtime）指的是：程序已经被加载到内存中成为进程，由操作系统启动之后，在程序执行过程中，为语言特性提供支持的一整套代码与机制。

实际上，我们写的 C++ 代码，编译后大致会变成三类东西：

• 我们实现的函数和逻辑
• 编译器插入的辅助代码
• 由标准库/编译器提供的支持代码

其中第二类和第三类，在程序执行时一起构成了我们常说的 C++ 运行时环境。

为什么栈展开要分成两个阶段？

读到这里你也许会疑惑：

为什么不从 throw 的地方开始，一边往上走，一边析构？非要先找 catch，再回头清理一次？

答案是：如果不分阶段，异常机制在语义上就会出错。

异常处理的真实流程：两阶段栈展开

在主流 C++ ABI（如 Itanium ABI）中，异常处理被明确拆分为两个阶段：

1. 搜索阶段（search phase）
2. 清理阶段（cleanup phase）

它们的职责是严格区分的。

第一阶段：搜索阶段（不做任何析构）

搜索阶段只做一件事：

从 throw 点开始，沿调用栈向上查找：是否存在一个能处理该异常的 catch？

这一阶段的特点非常重要：

• 不会析构任何对象
• 不会修改栈
• 只读取编译期生成的异常表
• 判断异常类型是否匹配某个 catch

为什么这一步不能析构？

因为在这个阶段，程序还不知道异常最终会落到哪里。

如果在搜索过程中就开始析构对象，一旦发现根本没有如何 catch 能处理这个异常。那么程序就会直接 std::terminate()，而这时已经提前破坏了栈和对象状态 —— 这是不可接受的。

所以结论是：

在确定'有人接得住异常'之前，绝不能做任何破坏性操作。

第二阶段：清理阶段（真正的栈展开）

只有当搜索阶段成功找到某个 catch 之后，才会进入第二阶段。

清理阶段才是真正意义上的栈展开：

• 从 throw 点开始
• 一路回溯到目标 catch 所在的栈帧
• 对中间每一层栈帧：
  1. 执行编译期生成的清理动作
  2. 调用已构造对象的析构函数
  3. 回到上一层栈帧

最终，控制流被转移到 catch 块中。

用一句话概括两阶段设计

搜索阶段负责'确认是否安全'，清理阶段负责'执行破坏性操作'。

为什么很多公司会禁用 C++ 异常机制？

在真正的工业代码中，你会发现一个现象：

在很多大型 C++ 项目（尤其是基础设施、服务端、游戏引擎）会明确使用 -fno-exceptions 禁用异常。

异常的代价是'不可预测的'

主要原因是：

异常的代价在时间和路径上都是不确定的

一旦 throw 发生：

• 要回溯多少层栈？
• 要析构多少对象？
• 会不会触发大量复杂析构逻辑？

这些是在编译器无法准确估计的。

异常会'隐藏控制流'，降低代码可读性

异常是非局部跳转，这意味着：

f(); // 这里可能直接跳走 

从这行代码本身，你看不出来：

• 它是否会抛异常
• 会跳到哪里
• 中间会执行哪些析构逻辑

对于规模很大的项目：控制流越隐式，排错和阅读起来就越困难，很反人类。因此很多团队更倾向于显示返回错误码。

异常一旦失控，后果往往是'直接终止进程'

如果异常：

• 没有被捕获
• 在 noexcept 修饰的函数中抛出

结果只有一个 std::terminate();

在长时间运行的服务中：

一次异常 ≈ 一次进程级事故

这是极大影响了系统的稳定性。

那什么时候应该用异常？

异常适合用于：不可恢复、低频、边界层的错误处理。

比如：

• 初始化失败
• 配置错误
• 构造失败
• 明确的'程序无法继续'的状态

而不是：

• 业务分支
• 常规失败
• 高频错误路径

总结：五分钟之后，你应该如何理解 C++ 异常？

异常是一种由编译期预先设计、在运行时按表执行的非局部控制流机制。

当 **throw**发生时，程序并不会沿正常路径返回，而是进入异常处理路径：

1. 先通过搜索阶段确认是否存在匹配的处理者
2. 再在清理阶段按照编译期生成的清理信息展开调用栈，保证已构造对象被正确析构
3. 最终将控制流转移到对应的 catch。

异常的价值在于为资源安全和错误传播提供语言级保证，但其代价体现在异常发生时的不可预测开销和隐式控制流，因此是否使用异常，本质上是一个工程取舍问题，而非语法选择。