c++协程中异常处理的关键在于异常的捕获、封装与传播。1. 协程内抛出的异常会被框架捕获并存储到promise_type中的exception_ptr；2. 父协程在co_await子协程时检查其状态并重新抛出异常；3. 实现自定义协程框架需在promise_type中保存异常、重写unhandled_exception方法并在awaiter中触发rethrow；4. 异常传播机制依赖框架设计，不同库实现可能不同，需注意文档说明及顶层异常捕获。
在C++协程中处理异常，其实和传统函数中的异常机制有些不同。协程的执行是分阶段的，可能被挂起再恢复，这就要求异常传播必须能跨越这些阶段。如果你希望在协程框架里正确地传递和处理异常，那得理解几个关键点：异常如何被捕获、封装并重新抛出，以及协程状态如何管理异常信息。
异常是如何进入协程状态的
当你在一个协程内部抛出异常时，这个异常不会像普通函数那样直接“冒泡”出去。它会被协程框架捕获，并存储到协程的状态对象（promise_type）中。这样做的好处是保证协程可以安全地退出当前执行阶段，而调用者可以在适当时机访问这个异常。
举个例子：
立即学习“C++免费学习笔记（深入）”；
taskmy_coroutine() { throw std::runtime_error("something went wrong"); }
在这个例子里，my_coroutine() 是一个返回 task 类型的协程（比如基于 cppcoro 或者你自己实现的协程类型）。当协程运行时抛出了异常，它会被封装进协程的状态中，而不是立即终止整个线程。
要让这个机制正常工作，你的 promise_type 必须重写 unhandled_exception() 方法，并保存异常指针（通常是 std::exception_ptr）供后续使用。
协程调用链上的异常传播方式
当协程 A 调用了协程 B，并且 B 抛出了异常，这个异常需要从 B 传播回 A，甚至继续往上传递。这通常通过协程句柄（coroutine_handle）和状态对象之间的交互来完成。
常见做法是：
- 在子协程中捕获异常并保存到 promise 中。
- 父协程在
co_await子协程时，检查其状态是否包含异常。 - 如果有异常，则父协程会重新抛出（rethrow）这个异常。
例如：
taskchild_coroutine() { throw std::runtime_error("child failed"); } task parent_coroutine() { co_await child_coroutine(); // 这里会触发 child 的异常 rethrow }
在这种情况下，parent_coroutine() 会在 co_await 表达式处重新抛出子协程的异常。这样你就可以在更高层进行统一的错误处理。
如何设计自己的协程框架支持异常传播
如果你想自己实现一个简单的协程框架来支持异常传播，有几个关键点要注意：
- promise_type 需要有成员变量保存 exception_ptr
- 在 unhandled_exception() 中捕获当前异常并保存起来
- 在 await_resume() 或类似方法中判断是否有异常，并 rethrow
示例结构如下：
struct my_promise {
std::exception_ptr ex;
void unhandled_exception() {
ex = std::current_exception();
}
void rethrow_if_any() {
if (ex) std::rethrow_exception(ex);
}
};然后，在 co_await 的 await_resume() 中调用 rethrow_if_any()，就能把异常传回到调用方。
另外，如果你的协程返回值是一个 future-like 对象，比如 task，那它的 get() 方法也应当检查异常并 rethrow，以便用户可以通过同步方式感知错误。
实际开发中需要注意的地方
虽然 C++20 提供了协程的基本设施，但标准并没有规定异常如何传播，这部分逻辑完全由框架开发者决定。因此：
- 不同协程库（如 cppcoro、Boost.Asio、UE5 的协程支持）对异常传播的实现略有差异。
- 一些库默认不传播异常，或者只在特定上下文中传播，需要查阅文档。
- 异步代码中异常传播容易被忽略，建议在顶层加全局 try-catch 捕获未处理的协程异常。
总的来说，C++协程中的异常处理并不复杂，但需要你对协程生命周期和状态管理有一定了解。只要 promise 和 awaiter 正确配合，异常就能像同步代码一样自然地传播。
基本上就这些。
