17370845950

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) ... } 更紧凑，也避免忘记检查中间步骤。

• 函数参数类型必须匹配：若 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 必须保持相同错误类型，否则编译失败。这不是缺陷，而是强制你提前设计错误域边界。