在日常的 C++ 开发实践中，当我们遇到程序运行时的错误处理需求时，究竟应该优先选择基于异常的 try-catch 机制，还是采用传统的返回错误码的方式？请结合你的实际开发经验，谈谈你在这两种处理错误的方法之间是如何权衡和选择的？

回答思路

1. 【回答框架 1】错误码方式是 C 语言时代的主流，核心思想是函数通过返回特定整数值或枚举来标识错误状态，调用方通过检查返回值判断是否出错。它的优点是流程显式、开销极低，适合性能敏感且异常路径稀少的内层代码；缺点是错误传播需要层层手动检查，容易遗漏，且难以携带丰富的错误上下文。
2. 【回答框架 2】try-catch 机制依托 C++ 的异常体系，抛出异常对象后，栈展开会自动寻找匹配的 catch 块。它适合处理构造、析构、资源获取等无法通过返回值表达的失败场景，也适合在大型项目中达成错误处理的关注点分离。但异常在部分嵌入式或实时系统里因栈展开成本高、关闭 RTTI 等因素不被支持。
3. 【回答框架 3】实践中更常见的成熟策略是混合使用：对于期望内、可恢复且频繁发生的错误（如用户输入校验），优先使用错误码，因为这类错误不算异常；对于意外、不可恢复或发生在深层调用栈中的错误（如内存分配失败、资源获取失败），使用 try-catch，避免每层都手动透传。是否需要携带额外错误信息也是选择的关键，异常对象可以携带任意结构化信息，而错误码往往只有一个数值。
4. 【回答框架 4】还要考虑团队与项目约束：很多大型项目，尤其是 Google 的很多开源 C++ 库，强制禁用异常，全部用错误码加 abseil Status 这类包装类型；如果项目启用了异常，也应保证抛出异常不会跨越模块边界，避免 ABI 兼容性问题。建议结合项目现有规范，统一错误处理风格，而不是反复横跳。
5. 【回答框架 5】最后，无论选哪种，都要把错误处理作为接口契约的一部分：错误码要定义清晰，异常要设计异常类层次，并约定捕获粒度与兜底策略。实际项目中我通常会为每个模块统一封装错误返回类型（如自定义 Status，内部含错误码与描述），在边界处转换错误表示，保证对外一致的风格。
6. 【关键点 1】错误码适合高频、可预期且调用方必须处理的局部失败；try-catch 适合低频、深层或资源型失败，能自动传播上下文。
7. 【关键点 2】选择时要重点考虑性能要求、错误传播距离、是否需要上下文信息，以及团队或框架是否禁用了异常特性。
8. 【关键点 3】大型项目常采用混合策略，以错误码封装类作为模块间错误返回的标准，必要时在边界转换为异常。
9. 【关键点 4】异常不能跨 DLL 或 C API 边界传播，错误码则天然兼容 C ABI，跨语言或插件场景必须选错误码。
10. 【关键点 5】错误处理方式必须写入接口契约，要么定义错误码，要么定义异常层次，全局保持统一风格。
11. 【易错点 1】把异常用于高频正常流程驱动的控制流，会导致性能和可读性双降，应仅用于真正的异常情况。
12. 【易错点 2】在构造函数中抛异常时，已构造的成员对象会被自动析构，但已分配的裸资源可能泄漏；若依赖错误码，构造失败又无法表达，需要权衡使用二段式构造或工厂函数。
13. 【易错点 3】错误码方式最容易犯的错误是忽略返回值或误用 0 与非 0 表达，导致错误被吞掉；异常方式则容易在 catch 后无脑吞掉或打印日志，没有重新抛出或转译错误，掩盖真实原因。