先说结论：
C++算法
C++ 异常机制深度解析：栈展开与控制流原理
C++ 异常机制是一种由编译期预先设计、在运行时按表执行的非局部控制流机制，用于在控制流被中断时保证对象析构与资源安全。其核心在于两阶段栈展开：搜索阶段查找匹配 catch 而不析构对象，清理阶段回溯调用栈并执行析构。异常在正常路径成本低，但抛出时开销大且隐式，导致部分工业项目禁用。适用于不可恢复、低频错误，而非业务分支。
C++ 异常机制是一种由编译期预先设计、在运行时按表执行的非局部控制流机制，用于在控制流被中断时保证对象析构与资源安全。其核心在于两阶段栈展开：搜索阶段查找匹配 catch 而不析构对象，清理阶段回溯调用栈并执行析构。异常在正常路径成本低，但抛出时开销大且隐式，导致部分工业项目禁用。适用于不可恢复、低频错误，而非业务分支。
先说结论：
C++ 异常是一种由编译期预先设计、在运行时按表执行的非局部控制流机制，用于在控制流被中断时仍然保证对象析构与资源安全。
它在正常路径上几乎没有成本，但一旦抛出就会触发昂贵且隐式的栈展开过程，因此是否使用异常，本质上是工程取舍而非语法选择。
在 C++ 里，异常是一个被大量使用，却很少被真正理解的机制。
你可能已经知道：
但是，如果进一步思考：
先看一段普通的代码：
void f() { throw std::runtime_error("error"); }
void g() { f(); }
int main() { try { g(); } catch (...) { } }
直觉上，我们认为：throw 就像一种**特殊的 'return'，**一层层返回，直到遇到 catch。
但这并不准确。
从底层的视角看，异常机制的本质特征是：
异常不是'逐层返回'，而是一次非局部跳转
也就是说：
这条路径的名字叫：栈展开 (stack unwinding)
栈展开可以理解成一个三阶段过程：抛出 → 寻找处理者 → 回溯清理并跳转。
当程序运行到：
throw std::runtime_error("oops");
底层至少发生两件事：
注意：此刻开始，控制流不再沿着我们写的函数继续往下走
异常运行时接管后，会做一件很关键的事：
从 throw 点出发，沿着调用栈向上查找：有没有在某一层存在匹配的 catch？
编译器在编译时会为每个函数生成异常相关的元数据（可理解为 异常表 / unwind 信息），**'运行时'**会根据这些信息判断：
如果一直找到 main 都没有匹配的 catch，**'运行时'**最终会走到 std::terminate()。
这一阶段的关键点是：
当'运行时'确定了'最终会被哪个 catch 接住' 之后，才开始真正的栈展开：
从 throw 所在的栈帧开始，一层层弹出栈帧，执行每层需要执行的清理代码。
编译器在编译时会为栈帧生成对应的清理逻辑，运行时会按顺序执行它们。
注：正常的函数作用域结束后，会执行编译器编译的析构指令，这是正常执行流；但异常执行流是走不到正常执行流的清理部分，所以编译器为异常执行流编译了特殊的清理逻辑（一种正常执行流被打断的补偿机制）
用一段代码感受：
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 (...) {} }
可以看到控制台输出：
(此处省略图片展示)
栈展开时析构发生的顺序是：
当 throw 点到 catch 点之前的栈帧都完成清理后：
到此为止，异常处理完成一次闭环：
找落点 -> 清理路径 -> 跳到 catch
先说定义：
运行时（runtime）指的是：程序已经被加载到内存中成为进程，由操作系统启动之后，在程序执行过程中，为语言特性提供支持的一整套代码与机制。
实际上，我们写的 C++ 代码，编译后大致会变成三类东西：
其中第二类和第三类，在程序执行时一起构成了我们常说的 C++ 运行时环境。
读到这里你也许会疑惑：
为什么不从 throw 的地方开始，一边往上走，一边析构？非要先找 catch，再回头清理一次？
答案是：如果不分阶段，异常机制在语义上就会出错。
在主流 C++ ABI（如 Itanium ABI）中，异常处理被明确拆分为两个阶段：
它们的职责是严格区分的。
搜索阶段只做一件事：
从 throw 点开始，沿调用栈向上查找：是否存在一个能处理该异常的 catch？
这一阶段的特点非常重要：
为什么这一步不能析构？
因为在这个阶段，程序还不知道异常最终会落到哪里。
如果在搜索过程中就开始析构对象，一旦发现根本没有如何 catch 能处理这个异常。那么程序就会直接 std::terminate()，而这时已经提前破坏了栈和对象状态 —— 这是不可接受的。
所以结论是：
在确定'有人接得住异常'之前，绝不能做任何破坏性操作。
只有当搜索阶段成功找到某个 catch 之后，才会进入第二阶段。
清理阶段才是真正意义上的栈展开：
最终，控制流被转移到 catch 块中。
搜索阶段负责'确认是否安全'，清理阶段负责'执行破坏性操作'。
在真正的工业代码中，你会发现一个现象：
在很多大型 C++ 项目（尤其是基础设施、服务端、游戏引擎）会明确使用 -fno-exceptions 禁用异常。
主要原因是：
异常的代价在时间和路径上都是不确定的
一旦 throw 发生：
这些是在编译器无法准确估计的。
异常是非局部跳转，这意味着：
f(); // 这里可能直接跳走
从这行代码本身，你看不出来：
对于规模很大的项目：控制流越隐式，排错和阅读起来就越困难，很反人类。因此很多团队更倾向于显示返回错误码。
如果异常：
结果只有一个 std::terminate();
在长时间运行的服务中：
一次异常 ≈ 一次进程级事故
这是极大影响了系统的稳定性。
异常适合用于：不可恢复、低频、边界层的错误处理。
比如：
而不是：
异常是一种由编译期预先设计、在运行时按表执行的非局部控制流机制。
当 **throw**发生时，程序并不会沿正常路径返回，而是进入异常处理路径：
catch。异常的价值在于为资源安全和错误传播提供语言级保证，但其代价体现在异常发生时的不可预测开销和隐式控制流，因此是否使用异常，本质上是一个工程取舍问题，而非语法选择。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online
将 Markdown（GFM）转为 HTML 片段，浏览器内 marked 解析；与 HTML转Markdown 互为补充。 在线工具，Markdown转HTML在线工具，online
将 HTML 片段转为 GitHub Flavored Markdown，支持标题、列表、链接、代码块与表格等；浏览器内处理，可链接预填。 在线工具，HTML转Markdown在线工具，online
通过删除不必要的空白来缩小和压缩JSON。 在线工具，JSON 压缩在线工具，online