C++如何使用std::expected处理带有错误上下文的返回

先说一个关键点：std::expected 对错误类型 E 的要求，比大多数人第一眼看到的要严格得多。它不只是“你得给我一个错误对象”，而是要求这个 E 必须是可复制或可移动的、非 void、且不能是引用或数组。这看起来是标准库的常规约束，但放在异常处理这个语境下，问题就来了——你没法直接把一个 std::exception 实例，尤其是一个携带了调用栈信息的自定义异常对象，当作 E 塞进去。除非你手动拷贝它的 what() 字符串，或者换一种方式，比如用 std::error_code 加几个额外字段来承载信息。

一个很常见的死胡同是这么写的：std::expected。编译会直接报错，提示 ‘std::runtime_error’ is not copyable。原因在于，C++23 之前的标准库实现大多禁用了不可复制类型作为模板参数。说白了，这条路走不通。

正确的做法是什么？

• 用 std::error_code 来表达系统级错误，这是一种轻量、可复制的方案。
• 或者，自己定义一个轻量的错误结构体，比如包含一个 enum class code 和一个 std::string_view context。
• 千万别想着用 std::exception_ptr 当 E。它虽然可复制，但用它承载错误信息，你会丢失原始的异常类型和消息上下文，语义上几乎等于白费功夫。
• 如果你真的需要完整的异常信息，那就封装成一个值语义类型，像这样：

  struct ContextualError {
      std::error_code ec;
      std::string context; // 比如 "failed to parse config at line 42"
  };

接下来这个点，很多人会忽略：如何让函数返回的错误带上文件名和行号这类调用点信息？std::expected 本身不提供这个能力，你必须主动注入。最简单的办法是在构造 E 时传进 __FILE__ 和 __LINE__ 这些宏。但要注意字符串的生命周期——__FILE__ 是静态字符串字面量，用 std::string_view 来存是安全的，不需要拷贝；__LINE__ 直接存为 int 就行。

有一点需要提醒：不要在 std::expected 的构造过程中调用 std::source_location::current()。C++20 提供的这个工具是运行时获取的，开销不小，而且多数编译器并没有对它做很好的优化。相比之下，直接用宏更省事、更可靠。比如这样：

std::expected read_int_from_file(const char* path) {
    if (!std::ifstream{path}) {
        return std::unexpected(ContextualError{
            std::make_error_code(std::errc::no_such_file_or_directory),
            std::string_view{"read_int_from_file at "} + std::string_view{__FILE__} + ":" + std::to_string(__LINE__)
        });
    }
    // ...
}

再聊聊 and_then 和错误传播中的陷阱。and_then 只会在成功值上被调用，但它返回的新 std::expected 的错误类型，必须和原来的错误类型完全一致——否则编译直接失败。这就意味着，如果不同层级的函数返回的错误类型不统一，你就不能指望无脑链式调用。

• 比如 f() 返回 std::expected，而 g() 返回 std::expected，那 f().and_then(g) 就会编译报错，除非 Err1 和 Err2 是同一个类型。
• 解决办法有两种：一是提前统一错误类型，比如所有函数都返回 ContextualError；二是用 transform_error 手动做类型转换：

  auto res = f().transform_error([](auto e) { 
      return ContextualError{e.ec, "wrapped from f: " + std::string(e.context)}; 
  }).and_then(g);

• 还要注意一点，and_then 不会自动展平嵌套的 std::expected>。它没有 flat_map 语义，这一点和真正的 monad 是不同的。

最后，看看 std::expected 和传统 try/catch 混用时的边界问题。这两者本质上是正交的——一个是值语义的错误处理，一个是异常机制。混用时最容易踩的坑是：异常逃逸的路径不会自动变成 std::unexpected，反过来也一样。

• 不要在 std::expected 函数内部 throw，除非你确实打算让上层的 catch 来处理。这等于打破了“无异常”的契约，会让代码意图变得混乱。
• 如果底层 API 必须依赖异常（比如 std::stoi），那就立即捕获，并转化为 std::unexpected：

  try {
      return std::stoi(s);
  } catch (const std::exception&) {
      return std::unexpected(ContextualError{
          std::errc::invalid_argument,
          std::string_view{"stoi failed on "} + s
      });
  }

• 编译器对 std::expected 的优化现在已经相当不错了（GCC 13+ 和 Clang 16+ 都做得很好），但如果你把一个函数声明为 noexcept，又在里面抛异常，就会直接触发 terminate。这个坑比裸指针还要隐蔽。

说到底，真正难的不是怎么写 std::expected，而是决定哪些错误该用它承载，哪些仍然应该走异常。比如 I/O 超时这类预期内的失败，用 expected 很合适；而内存分配失败这种意外崩溃，留给异常处理更合理。这个边界一旦划错，后面所有关于上下文注入的努力都会跑偏。