零成本异常并非完全无代价。其核心在于编译器优化使得正常流程无运行时开销，但会增加编译时间和二进制体积，因为需生成异常表记录栈回溯信息。若抛出异常，则涉及栈展开、类型匹配和对象析构等操作，带来显著性能损耗。相比之下，错误码方式运行时开销可控，适合嵌入式和实时系统，但代码冗长且易被忽略。合理使用异常应避免频繁抛出、确保析构函数不抛异常、使用noexcept说明符、缩小try块范围。最终选择取决于应用场景：性能敏感、错误少的系统宜用错误码，复杂恢复逻辑的系统宜用异常。
C++的异常处理机制虽然强大，但用不好也容易带来性能问题，特别是在对性能敏感的场景下。很多人会听说“零成本异常”这个概念，觉得异常就是没有运行时开销的，但实际上它的代价藏在别处。如果你关心程序性能，尤其是像服务器、嵌入式系统这种对延迟和资源敏感的项目，那就有必要深入理解异常机制，并考虑是否使用错误码替代。
零成本异常到底有没有成本？
“零成本”其实是编译器实现的一种优化策略：在不抛出异常的情况下，try块内的代码不会产生额外的运行时开销。这听起来很理想，但在背后，它带来了编译时间变长和二进制体积增大的问题。
这是因为编译器需要为每个可能抛出异常的函数生成一张“异常表”，记录哪些函数调用栈可以被 unwind（回溯）。这些信息在大多数现代C++编译器中是以某种形式存储在可执行文件中的，即使你从没抛过一次异常，这部分数据依然存在。
立即学习“C++免费学习笔记（深入）”；
所以，所谓的“零成本”只是说正常流程不受影响，但它并不意味着完全无代价。尤其是在大型项目中，这些副作用会变得明显。
异常 vs 错误码：性能对比
如果抛出异常了呢？那开销就不再是“零”了。异常的抛出涉及栈展开（stack unwinding）、类型匹配、对象析构等一系列操作，这些都会带来显著的性能损耗。
相比之下，错误码的方式则更加直接。比如：
- 函数返回一个枚举或布尔值表示成功与否
- 调用者检查返回值并做相应处理
这种方式的好处是：
- 运行时开销可控，只有出错时才处理
- 没有栈展开带来的不确定延迟
- 适合嵌入式、实时系统等场景
当然，错误码也有缺点，比如：
- 代码容易变得冗长
- 容易被忽略（特别是没有强制检查机制）
- 对于深层嵌套的错误传递不够灵活
所以，是否选择异常还是错误码，取决于你的应用场景。对于性能要求高、错误发生频率低的系统，错误码通常更合适；而对于错误种类多、恢复逻辑复杂的系统，异常反而能提升开发效率。
如何合理使用异常机制？
如果你决定使用异常，那也要注意一些常见的陷阱：
- 避免在频繁路径上抛出异常：异常应该用于“异常情况”，而不是控制流的一部分。
- 确保析构函数不抛出异常：否则可能导致未定义行为。
- 使用标准库的noexcept说明符：有助于编译器优化，也能提高代码健壮性。
- 尽量缩小try块范围：这样可以减少不必要的栈展开开销。
另外，有些编译器选项也可以帮助你评估异常的影响。例如，在GCC或Clang中使用-fexceptions来启用/禁用异常支持，或者通过工具分析二进制大小的变化。
小结一下
总的来说，C++的异常机制并不是完全没有成本的。虽然“零成本”的说法在某些情况下成立，但它隐藏了编译时间和二进制体积的代价。而错误码方式虽然写起来麻烦点，但在性能确定性方面更有优势。
基本上就这些。要不要用异常，还是要看具体场景，没有绝对的对错。
