对问题的回答。
问题的历史
在C++中，错误处理传统上依赖于异常或错误代码。异常提供了干净的语法，但会导致运行时开销，并且在像嵌入式系统或实时交易等确定性上下文中使用起来比较困难。错误代码高效但污染了函数签名，并且需要手动传播检查。C++23引入了std::expected，这是一种词汇类型，表示值或错误，灵感来自于函数式编程单子，如Haskell的Either或Rust的Result。
问题所在
虽然std::expected提供了像and_then、or_else和transform这样的单子操作，但是这些操作需要在每个组合链的每一步显式处理错误类型。与基于异常的处理不同，错误会自动在调用栈中传播直到被捕获，std::expected要求程序员显式指定如何在每个单子绑定中转换或传播错误。这种显式性在链接多个可能失败的操作时会产生冗长的代码，并且在不同的操作返回不同的错误类型时，需要仔细考虑错误类型转换。根本问题在于，**C++**的类型系统要求在模板实例化中显式错误类型统一，而不是动态异常处理。
解决方案
C++23的std::expected单子接口使用显式模板机制以确保类型安全和零开销抽象。and_then方法要求可调用对象返回另一个具有潜在不同错误类型的std::expected，实现使用SFINAE或概念来验证组合。为了错误类型传播，开发者必须显式使用or_else处理类型转换或使用transform_error映射错误类型。这种显式的方法确保错误处理路径在源代码中可见，并且可以被编译器优化，而不是隐藏的异常控制流。该解决方案在尊重**C++**的零开销哲学的同时，拥抱了函数式编程原则。
#include <expected> #include <string> #include <system_error> std::expected<int, std::error_code> parse_int(const std::string& s); std::expected<double, std::error_code> divide(int a, int b); // 组合中的显式错误处理 auto result = parse_int("42") .and_then([](int n) { return divide(100, n); }) .or_else([](std::error_code e) { return std::expected<double, std::error_code>(0.0); });
生活中的情况
一个医疗设备软件团队需要实现一个数据管道，处理带有多个验证阶段的传感器读数。每个阶段可能会因特定错误代码（硬件超时、校验和失败、校准错误）而失败，这些错误需要以完整的类型安全传播到日志系统。
考虑的第一个方法是使用基于异常的错误处理，使用std::runtime_error层次。这允许自动在调用栈中传播，并且将错误处理与业务逻辑干净地分离。然而，医疗设备要求确定性延迟保证，而异常在堆栈展开期间引入了不可预测的开销。这种方法还使得在禁用异常的GPU内核或嵌入式环境中使用代码成为不可能。团队需要一种在noexcept环境中工作的解决方案。
考虑的第二种方法是使用传统错误代码，使用std::optional或std::variant，在每次操作后进行手动错误检查。这提供了所需的确定性和noexcept兼容性。然而，代码在每个管道阶段之后变得杂乱，重复的if (!result)检查过于繁琐。错误传播需要手动将错误代码线程化通过调用栈，组合多个操作需要嵌套条件，这模糊了数据流逻辑。当混合来自不同硬件传感器的不同错误类别时，错误类型也缺乏类型安全。
最终选择的解决方案是C++23的std::expected及其单子接口。团队重构了管道，以使用and_then来链接验证步骤，并使用or_else进行错误转换。这保留了线性数据流，同时保持了显式错误处理路径。该解决方案提供了与noexcept约束兼容的零开销抽象，并允许准确的错误类型传播到日志系统。重构花费了三周，之后代码库支持15种不同类型的传感器，具有统一的错误处理。
候选人常常忽视的问题
std::expected在链接返回不同错误类型的操作时如何处理类型擦除？
候选人常常忽略std::expected默认情况下不执行类型擦除。当使用and_then时，可调用对象必须返回具有与原始相同错误类型的std::expected，否则程序不会编译。
为了处理不同的错误类型，开发者必须显式使用transform_error转换错误，或使用具有公共错误类型变体的std::expected。与使用单个静态类型（通常是std::exception_ptr或基本异常类）处理所有错误的异常不同，std::expected保持严格的类型安全。
这种设计防止了隐藏的类型擦除成本，但在编译时要求显式处理所有可能的错误状态。理解这一点对于组合来自不同库的操作以及具有不同错误类别是至关重要的。
为什么std::expected不提供像异常处理那样自动传播错误的单子绑定操作？
候选人常常将std::expected与基于异常的错误处理混淆，认为自动传播是理所当然的。他们期望如果链中的某个操作失败，后续操作会自动跳过，而无需显式处理。
尽管and_then在错误时跳过可调用对象，但错误类型仍然必须在链的末尾显式处理，或者使用or_else进行转换。根本原因在于，**C++**的类型系统要求显式处理所有可能的错误状态，以保持零开销和确定性行为。
自动传播将需要类似于异常的隐式控制流，这与显式、可优化的错误路径的设计目标相抵触。Std::expected优先考虑性能和确定性，而不是语法便利。
std::expected单子操作的noexcept规范如何影响组合链中的异常安全保证？
候选人常常忽视std::expected单子操作如and_then和transform是基于所调用的操作条件性noexcept的。如果传递给and_then的可调用对象是noexcept，则整个链保持noexcept。
然而，如果可调用对象可能会抛出，则该操作可能会抛出std::bad_expected_access或根据具体实现和错误处理策略传播异常。这种条件性noexcept传播允许开发人员在整个组合链中维护强大的异常安全保证。
理解这一点对于实时系统至关重要，其中异常规范影响代码生成和优化。noexcept合同通过单子链传播，确保错误处理保持确定性，并且可以被编译器优化。