std::expected 不能自动传播错误因其设计目标是替代 std::optional + 异常，而非函数式 Result；C++23 前无内置 monadic 操作，且值语义导致错误需手动展开分支。
std::expected 本身不支持链式错误回退，必须手动展开每个分支；直接套用 operator>>= 或仿照 Rust 的 ? 语法会踩空指针或忽略错误类型匹配。
为什么 std::expected 不能像 Result 那样自动传播错误
std::expected 是值语义类型，没有内置的 monadic 绑定操作（如 and_then 成员函数在 C++23 中才加入，且仅限单参数可调用对象）；它的设计目标是替代 std::optional + 异常，而非完全复刻函数式错误处理。常见误判是以为 expected 能安全跳过所有中间错误——实际一旦调用 value() 在 has_value() == false 时会抛 std::bad_expected_access，根本不是“回退”而是崩溃。
典型错误现象：
- 连续调用多个返回 std::expected 的函数后，只在最后检查一次 has_value()，中间任意一步失败都会导致后续访问非法
- 把 std::expected 当作“无返回值但可错误传播”的占位符，却忘了 void 类型无法参与 operator= 链式赋值
- 使用场景：配置加载 → 解析 JSON → 校验字段 → 写入数据库，任一环节失败需按顺序尝试备选路径（如本地缓存 → 默认配置 → 空初始化）
- 关键限制：C++23 前
std::expected没有transform_error或or_else，错误类型E必须可比较、可构造，且各分支的E最好统一（否则需显式std::visit） - 性能影响：每次
std::expected拷贝都触发E的拷贝构造，若E是含堆内存的错误信息类，应优先用std::expected而非自定义异常对象
手动展开多分支错误链的三步写法
核心思路：用 if-else 层叠捕获每个 std::expected 的错误，并在每个 else 分支中启动对应回退逻辑。不追求“一行链式”，而保证每步错误都有明确处置点。
示例：读取配置时，优先尝试网络获取，失败则 fallback 到本地文件，再失败用默认值：
auto load_config() -> std::expected<config configerror> {
auto net_res = fetch_from_network();
if (net_res) return net_res.value();
<pre class="brush:php;toolbar:false;">auto file_res = load_from_file();
if (file_res) return file_res.value();
return create_default_config(); // 返回 expected，非裸 Config
}
- 每个分支必须显式检查
if (res)，不能写if (res.has_value())—— 因为std::expected重载了operator bool()，更简洁且等价 - 所有分支返回类型必须严格一致（此处全是
std::expected），否则编译失败；若回退路径返回不同错误类型（如std::filesystem::error_code），需先转成统一的ConfigError枚举 - 避免在分支内直接
return res.value()后续无处理——这等于丢弃错误信息；应记录日志或构造带上下文的ConfigError::NetworkFailed再返回
用 std::variant + std::visit 实现动态错误分发
当各分支错误类型差异大（如网络层抛 std::system_error，解析层抛 json_parse_error），硬统一成一个枚举成本高，可用 std::variant 包装多种错误，再用 std::visit 分发处理逻辑。
示例：将三种错误归并为 std::variant<:system_error json_parse_error std::string>，然后按类型决定是否重试、降级或告警：
using MultiError = std::variant<:system_error json_parse_error std::string>;
auto handle_error(const MultiError& e) -> std::expected<config configerror> {
return std::visit([](const auto& err) -> std::expected<config configerror> {
using T = std::decay_t<decltype>;
if constexpr (std::is_same_v<t std::system_error>) {
log_warn("network error: {}", err.code());
return load_from_cache(); // 尝试缓存
} else if constexpr (std::is_same_v<t json_parse_error>) {
log_error("json invalid at line {}", err.line());
return std::unexpected(ConfigError::InvalidFormat);
} else {
log_fatal("unknown error: {}", err);
return std::unexpected(ConfigError::Unknown);
}
}, e);
}
</t></t></decltype></config></config></:system_error>
-
std::visit的 lambda 必须覆盖std::variant所有类型，否则编译失败；遗漏某个分支比运行时崩溃更早暴露问题 - 不要在
std::visit外部提前解包std::expected::error()——因为error()返回的是const E&，若E是临时对象（如函数返回的std::system_error），引用会悬空 - 这种写法适合错误策略差异大的场景，但增加了类型列表维护成本；日常业务中，优先用
enum class定义错误码，比std::variant更轻量、更易测试
最易被忽略的一点：std::expected 的移动语义在错误分支中常被绕过。比如写 auto res = func(); if (!res) return res; 看似正确，但如果 func() 返回的是右值 std::expected，这里发生的是拷贝而非移动——尤其当 E 是大对象时，性能损耗明显。真要优化，得写 auto&& res = func(); if (!res) return std::move(res);。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
