《从灾难恢复到优雅回归：在 C++20 Expected 协程中统一异常与错误码——打造健壮性与性能兼备的混合错误处理架构实践指南》 🚀
📝 摘要 (Abstract)
在工业级 C++ 开发中，完全禁绝异常往往是一种理想化的状态。当我们将 C++20 协程与 C++23std::expected结合时，必须面临一个核心挑战：如何将协程体内部“意外”发生的传统异常，转化为我们预期的“显式”错误值。本文将深入探讨协程 Promise 对象中unhandled_exception()的高级映射技巧，通过“重捕获（Rethrow-Catch）”模式，实现从异常模型到值模型的无缝转换，确保系统的错误处理链路在任何冲击下都能保持闭环与统一。
一、 异常映射器：将“非预期”转化为“可预期” 🛡️
1.1unhandled_exception的身份转换
在ExpectedTask中，unhandled_exception()不再仅仅是调用std::terminate的终结点，而是一个转换网关（Gateway）。它的使命是拦截一切抛出的异常，并尝试将其翻译为std::expected中定义的错误类型E。
1.2 重捕获（Rethrow-Catch）模式的精髓
要识别当前发生了什么异常，最专业的做法是在unhandled_exception()内部再次执行throw;。这允许我们在一个局部受控的try-catch块中通过类型匹配来识别异常种类。这种技术虽然看似奇特，但在 C++ 异常互操作层中是标准范式。
1.3 深度思考：类型安全的“兜底”机制
当异常无法识别时（例如未定义的第三方异常），我们必须在转换逻辑的最后提供一个catch(...)，将其映射为一个通用的“未知错误（Unknown Error）”。这防止了异常向上传播到没有准备好处理它的协程调用栈中，避免了进程崩溃。
二、 统一错误治理：构建混合模式的传播链路 ⚙️
2.1 异步链路中的错误透明度
当异常被映射为std::expected的错误分支后，后续的co_await链条将完全感知不到“异常”的存在，它们只会看到一个普通的、包含错误码的结果。这大大降低了调用方的代码复杂度，因为他们只需要处理一种错误表达形式。
2.2 性能权衡：映射的代价
必须承认，触发unhandled_exception依然涉及栈回退和std::exception_ptr的开销。但作为专家，我们的理念是：将异常仅用于真正的“异常”情况（如内存耗尽、硬件故障）。只要异常不发生在频繁的业务逻辑路径上，这种一次性的映射开销是可以接受的。
| 错误来源 | 处理机制 | 传播载体 | 性能开销 |
|---|---|---|---|
| 业务逻辑错误 | co_return std::unexpected | std::expected值 | 极低（近乎零） |
| 系统/库异常 | throw MyException() | unhandled_exception映射 | 高（仅触发时） |
| 未捕获异常 | catch(...)兜底 | E::UnknownError | 高（保护系统不崩溃） |
三、 实践案例：具备异常映射能力的ExpectedTask🛠️
在这个示例中，我们将展示如何捕获协程内部抛出的异常，并将其映射为业务定义的错误码。
#include<iostream>#include<coroutine>#include<expected>#include<stdexcept>#include<string>// 1. 定义业务错误码enumclassAppError{LogicError,MemoryError,UnknownSystemError};// 2. 具备异常映射能力的 Task 模板template<typenameT>structSecureTask{structpromise_type{std::expected<T,AppError>value;SecureTaskget_return_object(){returnSecureTask{std::coroutine_handle<promise_type>::from_promise(*this)};}std::initial_suspendinitial_suspend(){returnstd::suspend_never{};}std::final_suspendfinal_suspend()noexcept{returnstd::suspend_always{};}voidreturn_value(T v){value=v;}voidreturn_value(std::unexpected<AppError>e){value=e;}// 💡 核心实践：异常到错误值的映射网关voidunhandled_exception(){try{throw;// 再次抛出以进行类型识别}catch(conststd::bad_alloc&){value=std::unexpected(AppError::MemoryError);}catch(conststd::logic_error&){value=std::unexpected(AppError::LogicError);}catch(...){value=std::unexpected(AppError::UnknownSystemError);}std::cout<<"[Monitor] 检测到异常，已自动转换为错误码返回\n";}};std::coroutine_handle<promise_type>handle;~SecureTask(){if(handle)handle.destroy();}std::expected<T,AppError>result(){returnhandle.promise().value;}};// 模拟一个混合了“异常”和“显式错误”的业务函数SecureTask<int>perform_risky_calc(intmode){if(mode==0){// 场景 A: 显式返回错误值（Happy Path 错误处理）co_returnstd::unexpected(AppError::LogicError);}if(mode==1){// 场景 B: 第三方库抛出了异常（Unintended Exception）std::cout<<"[Action] 触发一个 std::logic_error 异常...\n";throwstd::logic_error("非法参数操作");}co_return42;}intmain(){// 处理异常转换后的结果autotask=perform_risky_calc(1);autores=task.result();if(!res){// 💡 调用方统一处理错误，无论是 throw 还是 co_return 产生的if(res.error()==AppError::LogicError){std::cerr<<"捕获到逻辑错误！\n";}elseif(res.error()==AppError::UnknownSystemError){std::cerr<<"捕获到未知系统崩溃！\n";}}else{std::cout<<"成功计算: "<<*res<<"\n";}return0;}四、 专业思考：构建“异常免疫”系统的架构哲学 🎓
3.1 异常映射的层级化
在大型系统中，不建议在每一个协程任务中都写复杂的try-throw-catch映射。专业的做法是定义一个基类 Promise或使用Mixin 模板来统一处理异常转换策略。这样可以确保整个项目的异常转换逻辑是高度一致的。
3.2 避免“二次异常”
在unhandled_exception()内部处理逻辑时，必须保证映射过程本身不会抛出异常。如果转换逻辑出错，程序将无可挽回地进入std::terminate。因此，映射逻辑应当尽可能简单、直接，并且使用noexcept的操作。
3.3 结论：从冲突走向统一
C++20 协程为我们提供了处理异步的骨架，std::expected为我们提供了表达结果的血肉，而unhandled_exception的映射机制则是保护这套系统免受外部异常冲击的盔甲。通过将异常转化为值，我们真正实现了异步编程的“确定性”，让 C++ 代码在面对复杂环境时依然能够保持优雅和稳健。
