告别异常与错误码：深入理解 C++23 的 std::expected

在 C++ 开发中，错误处理一直是一门平衡的艺术。随着 C++23 引入 std::expected<T, E>，我们终于拥有了一个能够在“显式控制”与“代码优雅”之间取得完美平衡的现代工具。

错误处理的历史博弈

在 std::expected 出现之前，C++ 开发者主要在以下三种模式中挣扎：

1. 原始的错误码（Return Codes）

这是从 C 语言继承而来的“老派”做法。函数通过 int 或 enum 返回状态，结果则通过参数指针/引用输出。

• 优点：零成本，完全透明。
• 缺点：错误码极易被调用者“静默忽略”，且输出参数使得函数无法声明为 const，降低了代码的表达能力。

2. 异常处理（Exceptions）

C++ 引入异常是为了将“业务逻辑”与“错误处理”分离。

• 哲学：异常只用于“不可预期的错误”，即那些发生概率极低、调用者无法恢复的致命情况。
• 隐性代价：在某些性能敏感的场景下，try-catch 的开销是不可忽略的。更糟糕的是，异常是隐式的——查看函数签名（如 int calculate()）无法得知它会抛出什么，这增加了大型项目的维护负担。

3. 可选值模式（Optional）

C++17 引入的 std::optional<T> 解决了“函数可能没有结果”的问题。

• 局限：它只能表达“成功”或“失败”。当失败发生时，它无法给出任何原因，这导致开发者最终还是不得不退回到错误码方案。

std::expected：现代化的解决方案

std::expected<T, E> 是一个“可判别的联合体”。它通过编译器强制要求调用者检查结果，同时为成功和失败提供了统一的通道。

核心特性深度解析

实战：从“嵌套地狱”到“函数式流水线”

在过去，处理一系列可能出错的操作往往导致“箭头型”代码（嵌套 if）：

// 传统写法：丑陋的嵌套
auto res1 = step1();
if (res1) {
auto res2 = step2(*res1);
if (res2) {
auto res3 = step3(*res2);
// …
}
}

使用 std::expected 的 monadic 接口，我们可以将其改写为清晰的流水线：

auto process() -> std::expected<Result, Error> {
return step1()
.and_then(step2)
.and_then(step3)
.transform(finalize);
}

• and_then：类似于 Optional::and_then，如果当前是成功，则传入下一个函数。
• transform：如果成功，对结果进行映射转换（如将 int 变为 string）。
• or_else：当发生错误时，提供一个回调函数来执行降级逻辑或记录日志。

最佳实践准则

• 简单的场景：直接使用 enum class ErrorCode。
• 复杂的场景：定义一个 struct，包含错误代码、上下文信息或错误消息。
• 避坑指南：避免在 E 中放置过大的对象（如过长的 std::string），这会增加所有返回 expected 的函数栈帧大小。

总结

std::expected 不仅仅是一个新的数据结构，它是一种编程哲学的转变。它鼓励开发者将错误视为数据的一等公民，通过类型系统来捕获潜在的逻辑缺陷。

对于开发者而言，学会使用 std::expected，意味着你的代码将不再依赖“隐式契约”，而是变得更加健壮、可读且易于测试。

在您的代码库中，有哪些函数目前是通过返回 -1 或 nullptr 来表示失败的？如果您尝试将其中一个重构为 std::expected，您认为目前最大的阻碍是什么？