错误码性能优但易忽略，std::optional语义清晰难忽略但无错误信息，std::expected兼顾两者，项目应统一错误处理方式。
在c++中处理错误，异常（exceptions）是一种常见方式，但并不是唯一选择。很多项目出于性能、可预测性或嵌入式环境限制等原因，会选择禁用异常。这时，错误码和 std::optional 成为两种主流的替代方案。下面从使用方式、语义清晰度、性能和适用场景等方面对比这两种方法。
错误码（Error Codes）
传统的C风格错误处理方式，在C++中依然广泛使用，尤其是系统级编程或性能敏感场景。
典型用法： 函数返回一个表示成功或失败的状态码（如 int、enum），实际结果通过引用参数输出。
示例：
enum class ErrorCode { Success, FileNotFound, PermissionDenied }; ErrorCode readFile(const std::string& path, std::string& outContent) { if (!fileExists(path)) { return ErrorCode::FileNotFound; } outContent = readFromDisk(path); return ErrorCode::Success; } // 调用 std::string content; ErrorCode result = readFile("config.txt", content); if (result != ErrorCode::Success) { // 处理错误 }
优点：
立即学习“C++免费学习笔记（深入）”；
- 无异常开销，编译选项无需开启 -fexceptions
- 性能稳定，控制流明确
- 适合系统编程、嵌入式、实时系统
缺点：
- 容易忽略错误检查（调用者可能不判断返回值）
- 语义不够清晰，需要额外文档说明哪个值代表错误
- 不能自然地链式调用或组合结果
std::optional 作为返回值
C++17 引入的 std::optional
示例：
std::optional<std::string> readFile(const std::string& path) { if (!fileExists(path)) { return std::nullopt; } return readFromDisk(path); } // 调用 auto result = readFile("config.txt"); if (result) { std::string content = *result; // 使用内容 } else { // 文件读取失败 }
优点：
立即学习“C++免费学习笔记（深入）”；
- 类型安全，不能忽略“无值”情况（虽然仍可能解引用 nullopt，但比忽略 int 返回值更明显）
- 语义清晰：返回 optional 意味着“可能失败”
- 支持现代 C++ 风格，可与 if 初始化、Lambda 等结合使用
- 可组合，配合 map、and_then 等模式（C++23 起支持部分链式操作）
缺点：
- 无法携带具体错误信息（除非包装成 variant 或自定义类型）
- 对简单错误场景可能显得“重”
- 某些嵌入式平台可能不支持或禁用 STL 组件
对比总结
下面是关键维度的对比：
| 维度 | 错误码 | std::optional |
|---|---|---|
| 性能 | 最优，零开销抽象 | 轻微开销（布尔标志 + 值） |
| 可读性 | 差，依赖命名和文档 | 好，意图明确 | 错误信息表达 | 可通过枚举扩展 | 仅表示“有无”，需配合其他机制 |
| 是否易被忽略 | 极易（返回值可完全不检查） | 较难（需显式判断） |
| 现代C++集成度 | 低 | 高 |
更进一步：std::expected（C++23）
如果既要返回值，又要携带错误信息，std::expected
示例：
#include <expected> std::expected<std::string, ErrorCode> readFile(const std::string& path) { if (!fileExists(path)) { return std::unexpected(ErrorCode::FileNotFound); } return readFromDisk(path); } auto result = readFile("config.txt"); if (result) { std::string content = *result; } else { handleErrorCode(result.error()); }
这结合了 optional 的清晰语义和错误码的信息表达能力，是异常的现代替代趋势。
基本上就这些。错误码适合极致性能和简单场景，optional 更适合表达“可能无结果”的逻辑，而 expected（或第三方如 tl::expected）是功能和清晰度的更好平衡。选择哪种，取决于项目约束和设计哲学。不复杂但容易忽略的是：让错误处理方式在整个项目中保持一致。
© 版权声明
文章版权归作者所有，未经允许请勿转载。
THE END
