问题的答案。
问题的历史
在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契约贯穿单子链，确保错误处理保持确定性且可被编译器优化。