《打破异步异常黑盒：深度揭秘C++20协程异常传播机制与工业级错误处理架构实践》 ⚡
📝 摘要 (Abstract)
传统的同步异常通过调用栈（Call Stack）自动向上回溯，但在异步协程中，由于原始调用栈可能早已销毁，异常的传播轨迹变得“支离破碎”。本文将深度剖析 C++20 协程底层如何通过unhandled_exception()钩子捕获异常，并详细阐述异常如何跨越挂起点，从“协程内部”安全地传输回“调用者/等待者”手中。我们将通过构建一个具备异常感知能力的Task<T>模板，展示工业级异步系统中错误传播的标准化范式。
一、 Promise：协程异常的第一守门人 🛡️
1.1unhandled_exception()：消失的catch块
当协程体内的逻辑抛出未捕获的异常时，编译器生成的代码并不会直接让程序崩溃。相反，它会立即跳转到 Promise 对象中的unhandled_exception()成员函数。这是协程给开发者的“最后机会”，用来决定如何处理这个烂摊子。
1.2std::exception_ptr：跨越线程的“灵魂捕获”
在unhandled_exception()中，最专业的做法是调用std::current_exception()。它会将当前异常封装进一个不依赖于具体类型的“灵魂”——std::exception_ptr。这个指针可以被安全地存储在 Promise 中，即使原本抛出异常的局部上下文已经销毁，它依然能保留完整的异常信息和类型。
1.3 深度思考：异常传播的“接力赛”
协程的异常处理本质上是一种状态转换。异常被捕获后，协程通常会立即流转到final_suspend。此时，协程虽然停止了，但它承载的“错误状态”正静静等待着下一次co_await时的唤醒。
二、 错误传播：从 Promise 到 Awaiter 的时空跳跃 🚀
2.1await_resume()：异常“重生”的关口
异常存储在 Promise 里只是第一步，真正让用户感知到错误发生，是在await_resume()中。当另一个协程co_await这个任务时，如果 Promise 中存有异常指针，我们应在此时调用std::rethrow_exception。这巧妙地模拟了同步调用的行为：你等待一个任务，如果它失败了，异常就在你等待的地方喷薄而出。
2.2 性能折中：异常 vs. 错误码 (std::expected)
虽然异常功能强大，但在极高性能要求的场景下，std::exception_ptr的分配是有开销的。现代 C++ 架构设计中，越来越多地结合 C++23 的std::expected或std::variant来进行无异常的错误传播。这种方式不仅更快，且在类型系统中强制要求开发者处理错误。
2.3 链式传播：嵌套协程的错误穿透
当协程 A 等待协程 B，B 又等待协程 C 时，任何一环的失败都会通过await_resume机制像多米诺骨牌一样向上传递。这种“自动穿透”特性是协程相对于回调函数（Callback Hell）最大的优势之一。
三、 实践案例：构建支持异常感知的Task<T>模板 🛠️
为了演示专业的错误处理，我们实现一个精简但功能完备的协程包装器。它体现了如何捕获、存储并在正确的时间点重新抛出异常。
#include<iostream>#include<coroutine>#include<exception>#include<stdexcept>/** * @brief 具备异常感知能力的协程任务模板 * 专业思考：通过 std::exception_ptr 实现异步错误的跨线程传播 */template<typenameT>structTask{structpromise_type{T result;std::exception_ptr exception;// 💡 存储异常的容器Taskget_return_object(){returnTask{std::coroutine_handle<promise_type>::from_promise(*this)};}std::initial_suspendinitial_suspend(){returnstd::suspend_always{};}std::final_suspendfinal_suspend()noexcept{returnstd::suspend_always{};}voidreturn_value(T value){result=value;}// 💡 编译器在异常发生时自动调用此钩子voidunhandled_exception(){exception=std::current_exception();// 捕获当前异常std::cout<<"[Log] Promise 捕获到内部异常\n";}};std::coroutine_handle<promise_type>handle;~Task(){if(handle)handle.destroy();}// 实现 Awaitable 接口boolawait_ready(){returnhandle.done();}voidawait_suspend(std::coroutine_handle<>h){handle.resume();h.resume();}// 💡 在 co_await 恢复时，决定是返回结果还是抛出异常Tawait_resume(){if(handle.promise().exception){std::cout<<"[Log] 正在重新抛出异常至调用者...\n";std::rethrow_exception(handle.promise().exception);}returnhandle.promise().result;}};// 模拟一个可能失败的异步计算Task<int>async_calculate(intinput){if(input<0){throwstd::invalid_argument("输入不能为负数！");}co_returninput*2;}// 调用方协程Task<void>run_demo(){try{intval=co_awaitasync_calculate(-5);// 这里会抛出异常std::cout<<"结果: "<<val<<"\n";}catch(conststd::exception&e){// 💡 就像同步代码一样捕获异步异常std::cerr<<"[Catch] 捕获到业务错误: "<<e.what()<<"\n";}co_return;}structSimpleTask{structpromise_type{SimpleTaskget_return_object(){return{};}std::initial_suspendinitial_suspend(){returnstd::suspend_never{};}std::final_suspendfinal_suspend()noexcept{returnstd::suspend_always{};}voidreturn_void(){}voidunhandled_exception(){}};};intmain(){run_demo();return0;}四、 专业思考：异常处理的深度架构考量 🎓
3.1 异常安全性与final_suspend的“生死时速”
在final_suspend中，绝对不允许抛出异常！如果这里发生异常，程序将直接调用std::terminate。作为专家，我们必须确保 Promise 的析构和清理逻辑是noexcept的，因为此时协程栈已经处于销毁阶段，没有任何机制能再接住新的异常。
3.2 调试的痛苦：丢失的符号栈
异步异常最让人头疼的是，当你捕获到异常时，原始的throw点处的调用栈信息往往已经丢失了。专业建议：在unhandled_exception()中通过日志库记录当时的上下文状态，或者结合 C++23 的std::stacktrace捕获当前的调用快照，这对生产环境的故障排查至关重要。
3.3 结论：构建鲁棒性的异步契约
C++20 协程通过 Promise 机制，将异常从一种“运行时灾难”转化为了可管理的“状态数据”。掌握unhandled_exception与await_resume的联动，是编写健壮、可维护异步代码的分水岭。在现代架构设计中，我们应当始终坚持：要么让异常明确地传播，要么用std::expected明确地返回错误。
