C++异常替代方案 错误码optional对比

错误码性能优但易忽略，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) {
    // 处理错误
}

优点：

唱鸭

音乐创作全流程的AI自动作曲工具，集 AI 辅助作词、AI 自动作曲、编曲、混音于一体

下载

立即学习“C++免费学习笔记（深入）”；

• 无异常开销，编译选项无需开启 -fexceptions
• 性能稳定，控制流明确
• 适合系统编程、嵌入式、实时系统

缺点：

• 容易忽略错误检查（调用者可能不判断返回值）
• 语义不够清晰，需要额外文档说明哪个值代表错误
• 不能自然地链式调用或组合结果

std::optional 作为返回值

C++17 引入的 std::optional 可用于表示“可能有值，也可能没有”的情况，适合表达计算可能失败的函数。

std::optional 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::expected（C++23）

如果既要返回值，又要携带错误信息，std::expected 是更好的选择，它是 optional 的增强版，允许返回成功值或错误值（如错误码或字符串）。

#include 

std::expected 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）是功能和清晰度的更好平衡。选择哪种，取决于项目约束和设计哲学。不复杂但容易忽略的是：让错误处理方式在整个项目中保持一致。