c++如何使用std::expected处理错误_c++ 23返回值与错误码封装【方法】

顺亿

2026-09-23 • 👁 0人浏览过

std::expected适用于可预见的业务失败场景，如文件打开失败、网络请求错误等，需显式处理而非异常；构造须指定成功/失败态，取值应避免直接调用value()以防终止。 std::expected 是 C++23 中真正可用的“结果类型”，它比手动传

std::error_code*

或抛异常更轻量、更可控，但用错地方反而会让错误处理更混乱。什么时候该用

std::expected

而不是异常？适合明确区分“预期失败”和“意外崩溃”的场景：比如文件打开失败（路径不存在、权限不足）、网络请求返回 404/503、JSON 解析字段缺失——这些是业务逻辑中可预见、需分支处理的失败，不是程序 bug。函数签名清晰暴露可能失败：

std::expected<:string std::errc>

比

std::string

+ 注释“失败时抛

std::system_error

”更可靠调用方无法忽略错误：必须显式检查

.has_value()

或用

.value_or()

.and_then()

避免异常开销或禁用异常环境（嵌入式、游戏引擎底层）不适用于需要栈展开清理资源的场景（比如构造函数中途失败且持有 RAII 对象）

std::expected

的基本构造与取值方式不能像

std::optional

那样默认构造成功值；必须显式指定成功或失败态。常见误区是误用

value()

导致未定义行为。构造成功值：

std::expected{42}

或

std::make_expected_from_current_exception(42)

构造失败值：

std::expected{std::unexpect, std::errc::no_such_file_or_directory}

安全取值：

e.value_or(-1)

（失败时返回默认值），

e.has_value() ? e.value() : handle_error(e.error())

危险操作：

e.value()

在

e.has_value() == false

时直接

std::terminate

，无异常抛出

auto read_config() -> std::expected {
    std::ifstream f{"config.json"};
    if (!f.is_open()) {
        return std::unexpected{std::errc::no_such_file_or_directory};
    }
    std::string content{std::istreambuf_iterator{f}, {}};
    return content;
}

// 使用
auto result = read_config();
if (result) {
    parse_json(result.value());
} else {
    std::cerr << "Config load failed: " 
              << std::make_error_code(result.error()).message() << "\n";
}

链式调用：用

.and_then()

替代嵌套

if

.and_then()

接收一个返回

std::expected

的函数，自动短路失败路径；比手写

if (ok) { auto r2 = f2(); if (r2) ... }

更紧凑，也避免忘记检查中间步骤。 php版微信js-sdk支付接口类 php版微信js-sdk支付接口类下载立即学习 “ C++免费学习笔记（深入） ”；函数参数类型必须匹配：若

e

是

std::expected

，则

e.and_then(f)

要求

f

签名为

T → std::expected

（错误类型必须一致）不支持跨错误类型转换，如需统一错误码，提前用

std::variant

封装或转换为通用枚举

.map()

仅转换成功值，不改变是否失败；

.or_else()

仅在失败时执行，用于 fallback 或日志

auto load_and_validate() {
    return read_config()
        .and_then([](std::string s) -> std::expected {
            auto cfg = parse_json(s);
            if (!cfg.is_valid()) {
                return std::unexpected{std::errc::invalid_argument};
            }
            return cfg;
        })
        .and_then([](Config c) -> std::expected {
            if (!c.has_required_field()) {
                return std::unexpected{std::errc::state_not_recoverable};
            }
            return c;
        });
}

与旧式错误码（

std::error_code

）的互操作要点

std::expected

不自动兼容

std::error_code

；它的错误类型是模板参数，需显式选择。用

std::errc

最轻量，但缺乏自定义上下文；用

std::error_code

需注意 category 生命周期。推荐起始方案：

std::expected

—— 标准错误码，零成本，适合系统调用封装需要自定义错误信息时：

std::expected

，但必须确保 category 全局存活（例如用

std::generic_category()

或静态注册的 category）避免

std::expected

：无法参与错误分类、比较、国际化，且拷贝开销大不要把

std::exception_ptr

塞进

expected

：失去静态类型优势，又没获得异常的栈展开能力最易被忽略的是错误类型的传播一致性：一旦在某个接口用了

std::expected

，下游所有

and_then

必须保持相同错误类型，否则编译失败。这不是缺陷，而是强制你提前设计错误域边界。

相关文章