C++23 前瞻：std::expected，更强大的错误处理机制

错误处理，一直是 C++ 里让人又爱又恨的话题。异常好用，但性能开销和代码膨胀让人头疼；错误码轻量，但写起来啰嗦，还容易漏掉检查。我个人习惯在性能敏感的模块里用错误码，但每次看到那堆 if (ret != SUCCESS) 的嵌套，心里就堵得慌。

C++23 引入的 std::expected，说白了就是给错误码穿上了类型安全的外衣。它让你既能享受值语义的高效，又能像异常一样自然地传播错误。嗯，这玩意儿我期待很久了。

1. 什么是 std::expected？

std::expected<T, E> 是一个模板类。它要么包含一个类型为 T 的正常值，要么包含一个类型为 E 的错误值。你可以把它想象成一个更安全的 std::variant，或者一个带错误信息的 std::optional。

我在项目中遇到过不少场景：一个函数可能返回计算结果，也可能因为输入非法而失败。以前我会用 std::pair<bool, T> 或者输出参数，但调用方很容易忘记检查那个 bool。用 std::expected，你不检查错误，编译器甚至会给你警告——这感觉就踏实多了。

2. 基本用法

先看一个最简单的例子。假设我们要解析一个字符串为整数：

#include <expected>
#include <string>
#include <charconv>
#include <system_error>

std::expected<int, std::errc> parse_int(const std::string& s) {
    int value;
    auto [ptr, ec] = std::from_chars(s.data(), s.data() + s.size(), value);
    if (ec == std::errc()) {
        return value;  // 正常返回
    } else {
        return std::unexpected(ec);  // 返回错误
    }
}

调用方可以这样用：

auto result = parse_int("42");
if (result) {
    std::cout << "解析成功: " << *result << "\n";
} else {
    std::cout << "解析失败，错误码: " << static_cast<int>(result.error()) << "\n";
}

注意那个 std::unexpected。它不是异常，而是一个工厂函数，用来构造 expected 的错误状态。你想想看，这比返回 -1 或者 nullptr 要清晰得多吧？

3. 链式调用与组合

std::expected 真正的威力在于组合。它提供了 and_then、or_else、transform 等方法，让你可以像流水线一样处理数据。

举个例子，假设我们要从配置文件里读取一个端口号：

std::expected<int, std::string> read_port(const std::string& config) {
    // 模拟读取配置
    if (config.empty()) {
        return std::unexpected("配置文件为空");
    }
    // 假设解析出端口号 8080
    return 8080;
}

std::expected<int, std::string> validate_port(int port) {
    if (port < 1024 || port > 65535) {
        return std::unexpected("端口号超出范围");
    }
    return port;
}

// 链式调用
auto result = read_port("myapp.conf")
              .and_then(validate_port)
              .transform([](int port) { return port * 2; });

if (result) {
    std::cout << "最终端口: " << *result << "\n";
} else {
    std::cout << "错误: " << result.error() << "\n";
}

我曾经在解析网络协议时用过类似的链式调用。每个解析步骤都可能失败，但用 and_then 串联起来，代码变得非常线性，不再有层层嵌套的 if 检查。说实话，写起来有种函数式编程的快感。

4. 与异常和错误码的对比

为了让你更直观地理解，我画了一张对比图：

从图上你能看出来，std::expected 试图在性能和安全性之间找到平衡点。它没有异常那样的运行时开销，但通过类型系统强制你处理错误。说白了，它就是要让你写出既快又安全的代码。

5. 避坑指南

我曾经在项目里犯过一个低级错误：把 std::expected 当成了 std::optional 来用，只检查了 has_value()，却忘了处理错误值。结果程序在某个边界条件下静默地使用了默认值，导致数据写错了。

这里有几个坑，你一定要注意：

• 不要忽略错误：std::expected 的 value() 方法在无值时抛出 std::bad_expected_access 异常。如果你不想抛异常，用 operator* 或 value_or()。
• 错误类型要合理：别用 std::string 当错误类型，字符串拷贝开销大。用 std::error_code、std::errc 或者自定义的轻量枚举。
• 不要滥用：对于构造函数、赋值运算符等频繁调用的地方，std::expected 的拷贝可能比异常还慢。性能热点处还是用错误码吧。

6. 实际项目中的使用建议

我个人建议这样用：

1. 库内部接口：用 std::expected 替代错误码，让调用方无法忽略错误。
2. 性能关键路径：用 std::expected 替代异常，避免 RTTI 和栈展开的开销。
3. 与旧代码交互：在边界处将 std::expected 转换为异常或错误码。

举个例子，我在写一个网络库时，底层解析函数全部返回 std::expected，上层业务逻辑再用 and_then 组合。这样底层干净利落，上层也清晰明了。嗯，代码评审的时候，同事们都觉得这种写法比之前好理解多了。

7. 总结

std::expected 是 C++23 给错误处理带来的一股清流。它不取代异常，也不取代错误码，而是在两者之间提供了一个优雅的中间地带。你想想看，当你能用类型系统来保证错误被处理时，是不是比靠自觉要靠谱得多？

如果你还在用 C++17，别急，Boost.Outcome 和 tl::expected 都是很好的替代品。等 C++23 全面普及了，std::expected 一定会成为你工具箱里的常客。

---