C++错误处理：从异常到std::expected的演进与实践

1. 现代C++错误处理的困境与演进

在C++社区摸爬滚打十几年，我见证了异常机制从被热捧到逐渐被质疑的全过程。异常处理确实优雅——当系统抛出FileNotFoundException时，我们可以在调用栈的任意层级捕获它。但这种"魔法"般的特性背后隐藏着代价：根据LLVM团队的测试数据，异常抛出路径的执行时间可能比普通返回慢100-400倍，因为需要动态生成栈回溯信息并进行类型匹配。

更棘手的是现实工程中的兼容性问题。我曾参与过一个跨平台项目，其中Windows模块使用SEH异常，Linux模块使用C++异常，最终不得不通过痛苦的适配层来桥接。这也是为什么像Google这样的技术巨头会在其C++编码规范中明确禁止异常使用。

正是在这样的背景下，std::expected提案（P0323R7）应运而生。这个来自Haskell的Either monad概念的模板类，通过将返回值与错误信息封装为代数数据类型，为C++带来了全新的错误处理范式。它的核心思想很简单：

cpp复制template<class T, class E>
class expected {
    union {
        T value;
        E error;
    };
    bool has_value;
};

这种设计实现了零开销抽象——在编译期就确定所有类型信息，运行时仅增加一个bool的判断开销。在我最近参与的量化交易系统中，将关键路径的错误处理从异常改为std::expected后，错误处理耗时从平均15μs降到了3μs。

2. 性能开销的深度对比

2.1 异常机制的隐藏成本

异常处理的性能特征非常特殊：快乐路径（没有异常抛出）几乎没有额外开销，但悲伤路径（抛出异常）的成本高得惊人。这是因为现代编译器通常采用表驱动（table-driven）的异常处理实现，需要在抛出异常时：

1. 展开调用栈，逐个检查栈帧中的异常处理表
2. 匹配catch子句的类型
3. 必要时调用析构函数
4. 复制异常对象

以下是一组实测数据（GCC 11.2，x86_64）：

2.2 std::expected的确定性开销

相比之下，std::expected的表现完全可预测：

cpp复制std::expected<int, Err> parseNumber(string_view s) {
    if (s.empty()) return std::unexpected(Err::EmptyString);
    // 解析逻辑...
}

auto result = parseNumber("123");
if (!result) {
    // 错误处理
} else {
    use(*result);
}

这种模式在每个调用点都引入了一个分支预测，但现代CPU的分支预测器可以很好地处理这种模式。在错误率低于5%的场景下，std::expected的性能优势非常明显。

提示：在热路径上使用[[likely]]/[[unlikely]]属性可以帮助编译器优化分支预测：

cpp复制if (!result) [[unlikely]] {
    // 错误处理
}

3. 代码可读性与维护性对比

3.1 异常导致的控制流断裂

异常处理最令人头疼的问题是其"隐式控制流"特性。考虑以下代码：

cpp复制void processTransaction() {
    try {
        auto conn = getDBConnection();
        auto data = fetchData(conn);  // 可能抛出
        auto result = calculate(data); // 可能抛出
        updateDB(conn, result);       // 可能抛出
    } catch (const DBError& e) {
        // 所有数据库错误都在这里处理
    }
}

当calculate()抛出异常时，updateDB()将不会执行，但conn的清理逻辑依赖于RAII。这种隐式的控制流转移使得代码难以调试——你无法仅通过阅读代码确定哪些操作可能被跳过。

3.2 std::expected的显式错误处理

使用std::expected的版本则完全不同：

cpp复制std::expected<void, Error> processTransaction() {
    auto conn = getDBConnection();
    if (!conn) return std::unexpected(conn.error());
    
    auto data = fetchData(*conn);
    if (!data) return std::unexpected(data.error());
    
    auto result = calculate(*data);
    if (!result) return std::unexpected(result.error());
    
    return updateDB(*conn, *result);
}

虽然代码看起来更冗长，但每个可能失败的点都清晰可见。C++23引入的monadic接口进一步改善了可读性：

cpp复制std::expected<void, Error> processTransaction() {
    return getDBConnection()
        .and_then([](auto& conn) { return fetchData(conn); })
        .and_then([](auto& data) { return calculate(data); })
        .and_then([](auto& result) { return updateDB(result); });
}

这种风格既保持了显式错误处理，又接近异常风格的流畅性。

4. 错误传播机制的差异

4.1 异常的错误信息丢失问题

在多层调用的系统中，异常经常导致原始错误上下文丢失：

cpp复制void inner() { throw std::runtime_error("file not found"); }

void middle() { 
    try { inner(); }
    catch (...) { throw std::system_error(ENOENT, std::system_category()); }
}

void outer() {
    try { middle(); }
    catch (const std::system_error& e) {
        // 原始错误信息已经丢失
    }
}

虽然C++11引入了std::nested_exception，但实际使用中很少见到。

4.2 std::expected的错误链支持

std::expected可以与C++23的std::error_code改进完美配合：

cpp复制struct DetailedError {
    std::error_code ec;
    std::string context;
    std::source_location loc;
};

std::expected<Data, DetailedError> parseConfig(std::string_view json) {
    auto result = parseJson(json);
    if (!result) {
        return std::unexpected(DetailedError{
            .ec = make_error_code(ParseErrc::InvalidJson),
            .context = format("Failed to parse config: {}", json),
            .loc = std::source_location::current()
        });
    }
    // ...
}

这种模式保留了完整的错误上下文，甚至可以构建错误链：

cpp复制std::expected<void, Error> process() {
    auto config = parseConfig("...");
    if (!config) {
        return std::unexpected(Error{
            .code = AppErrc::ConfigError,
            .details = config.error()
        });
    }
    // ...
}

5. 类型系统与编译期检查

5.1 异常的类型安全问题

C++异常最大的类型系统缺陷在于任何类型都可以被抛出：

cpp复制void risky() {
    throw "oops";  // 抛出字符串字面量
    throw 42;      // 抛出int
}

这导致catch块必须处理所有可能的异常类型，或者使用catch(...)这种"黑洞"式的捕获。

5.2 std::expected的强类型约束

std::expected在编译期就确定了所有可能的错误类型：

cpp复制std::expected<Data, std::variant<IOError, ParseError>> loadData() {
    // 只能返回Data、IOError或ParseError
}

结合C++20的concept，可以实现更强大的约束：

cpp复制template<typename E>
concept ErrorType = requires(E e) {
    { e.message() } -> std::convertible_to<std::string>;
};

template<typename T, ErrorType E>
class strict_expected : public std::expected<T, E> {
    // ...
};

这种设计使得编译器可以在编译期验证所有错误路径是否都被正确处理。

6. 工程实践中的选择建议

经过多个项目的实践验证，我总结出以下决策矩阵：

在混合使用时的经验法则：

1. 在模块边界定义明确的错误类型
2. 内部使用std::expected处理可恢复错误
3. 仅对程序无法继续执行的场景保留异常
4. 通过工具确保异常安全（如clang-tidy检查）

一个典型的混合使用示例：

cpp复制std::expected<Result, AppError> businessLogic() {
    auto input = validateInput();
    if (!input) return std::unexpected(input.error());
    
    try {
        return doCriticalOperation(*input);
    } catch (const CriticalFailure& e) {
        std::terminate();  // 不可恢复错误
    }
}

7. 常见问题与解决方案

7.1 错误类型设计

问题：如何设计良好的错误类型？

方案：

• 使用std::error_code作为基础
• 添加上下文信息（如失败的操作、参数值）
• 支持错误链（C++23的std::error支持嵌套）

cpp复制struct OperationError {
    std::error_code ec;
    std::string operation;
    std::optional<std::any> context;
};

7.2 性能敏感场景优化

问题：std::expected的bool检查影响性能？

方案：

• 使用[[likely]]/[[unlikely]]提示分支预测
• 对高频小对象使用std::expected<T*, E>
• 错误路径使用廉价的错误码，仅在需要时转换为丰富错误

cpp复制std::expected<int*, int> fastLookup() {
    static thread_local int cache[1024];
    if (hit) return &cache[index];
    return std::unexpected(ENOENT);
}

7.3 与现有代码集成

问题：如何与遗留异常代码交互？

方案：提供转换适配器

cpp复制template<typename T>
std::expected<T, ExceptionPtr> catch_exception(std::function<T()> f) {
    try {
        return f();
    } catch (...) {
        return std::unexpected(std::current_exception());
    }
}

8. 未来演进方向

随着C++26的临近，std::expected可能会获得更多强大特性：

1. 模式匹配集成：

cpp复制auto result = parseInput();
inspect (result) {
    expected value => process(value);
    unexpected err => log(err);
};

2. 更丰富的Monadic操作：

cpp复制auto result = getConfig()
    .and_then(validateConfig)
    .or_else(useDefaultConfig)
    .transform(encodeConfig);

3. 编译器优化提示：

cpp复制[[optimize_for_expected]]
std::expected<Data, Error> loadData();

在实际工程中，我建议渐进式采用std::expected：从新代码开始，逐步重构关键路径，同时建立团队共识。对于性能敏感项目，可以先用简单的bool+error_code组合，待工具链成熟后再迁移到完整方案。