使用异常在无抛出时性能开销小，但抛出时代价高。1.正常流程中两者差异不大，现代编译器优化使异常处理几乎不影响性能；2.错误频繁发生时异常效率远低于错误码，因涉及堆栈展开和rtti查找；3.错误极少时推荐用异常，代码更整洁且适合raii。选择应基于场景：罕见错误、需跨层传递、重视可读性时用异常；高频错误、极致性能需求或老旧平台则选错误码。
C++的异常处理机制在现代编程中是一个很有争议的话题，尤其在性能敏感的场景下。很多人关心：使用异常到底会不会拖慢程序？和传统的错误码方式相比，哪个更高效？
答案是：在没有异常抛出的情况下，现代编译器对异常处理的开销已经非常小；但在真正抛出异常时，代价可能很高。
异常处理的基本机制与运行时开销
C++的异常处理依赖于堆栈展开（stack unwinding）和动态类型匹配。当异常被抛出时，程序会从当前函数开始逐层回退，查找匹配的catch块。
立即学习“C++免费学习笔记（深入）”；
这个过程包括：
- 查找调用链中的异常处理信息
- 调用局部对象的析构函数（RAII）
- 找到匹配的
catch语句并跳转执行
这些操作在正常流程中不会发生，只有在抛出异常时才会触发。所以，异常的开销是“惰性”的，也就是平时不花什么代价，但一旦触发就比较重。
异常 vs 错误码：效率对比分析
我们来具体看看两种方式在不同场景下的表现：
1. 正常流程中（无异常）
-
异常处理：现代编译器（如GCC、Clang、MSVC）通常采用表驱动的方式记录异常处理信息，这意味着即使你用了
try/catch，也不会显著影响正常执行路径的性能。 - 错误码：直接返回状态值，逻辑清晰，开销几乎为零。
结论：在这个阶段，两者差异不大，甚至可以忽略。
2. 错误频繁发生的场景
- 异常处理：如果异常经常被抛出，那性能问题就会显现。因为每次抛出都涉及堆栈展开、RTTI查找等，这些操作可能比简单的错误判断慢几个数量级。
- 错误码：通过函数返回值判断即可，成本固定且可控。
比如在解析输入数据时，若格式错误频繁出现，用异常反而成了负担。
3. 错误极少发生的情况
- 异常处理：在这种情况下，异常的高开销很少被触发，而代码结构却更加整洁，有利于维护。
- 错误码：虽然效率略高，但需要层层检查返回值，容易遗漏或造成冗余判断。
这类场景适合用异常，比如内存分配失败、文件打开失败等罕见情况。
实际开发中如何选择？
关键在于理解你的应用场景：
✅ 推荐使用异常的情况：
- 错误是罕见的，且难以通过常规流程处理
- 需要跨多层调用栈传递错误
- 更看重代码可读性和资源安全（比如RAII）
❌ 更适合用错误码的情况：
- 错误频繁发生，属于正常流程的一部分
- 对性能要求极高，尤其是嵌入式系统或高频交易系统
- 编译器不支持高效的异常处理（某些旧平台或特定编译选项）
另外，有些项目或公司出于历史原因或编码规范，会禁用异常，这时你就只能用错误码了。
一些细节上的建议
- 不要在性能关键路径上频繁抛出异常，特别是循环体内。
- 使用
noexcept标记那些肯定不会抛出异常的函数，有助于优化。 - 如果你不确定是否启用异常，可以在构建配置中保留开关，按需启用。
- 对于库开发者，考虑提供两种接口：一种基于异常，一种基于错误码，供使用者选择。
基本上就这些。异常不是洪水猛兽，也不是银弹，关键看你怎么用。
