必须显式调用rethrow_nested()才能获取嵌套的原始异常，直接catch(std::nested_exception&)只能捕获占位符，其what()为空或抛出bad_exception。
std::nested_exception 的捕获必须显式 re-throw 原异常
直接 catch (const std::nested_exception&) 捕获不到嵌套异常本身——它只是个“占位符”，不携带原始异常类型信息。真正要拿到被嵌套的异常，必须在 catch 块里调用 rethrow_nested()，否则你只能看到空的 what() 或抛出 std::bad_exception。
典型错误写法：
try {
throw std::runtime_error("outer");
} catch (const std::nested_exception& e) {
// ❌ 这里 e 不是原始异常，且 e.what() 通常为空
std::cout << e.what(); // 可能输出空字符串
}正确做法是让它参与异常链：用 std::throw_with_nested 抛出，再用两层 catch 配合 rethrow_nested() 展开：
- 外层
catch (const std::nested_exception&)捕获链头 - 立即调用
e.rethrow_nested()触发内层异常重抛 - 用另一个
catch（可嵌套或用函数封装）捕获实际异常类型
std::throw_with_nested 是构建异常链的唯一可靠入口
std::throw_with_nested 不是“包装器”函数，而是强制将当前异常对象作为嵌套异常挂载到新异常上，并要求新异常类型继承自 std::nested_exception。这意味着：如果你自定义异常类想支持嵌套，必须公有继承 std::nested_exception，否则 throw_with_nested 会静默失败或抛出 std::bad_exception。
立即学习“C++免费学习笔记（深入）”；
常见误用场景：
- 对非继承
std::nested_exception的类使用throw_with_nested→ 编译可能通过，但运行时丢失嵌套 - 在无活跃异常的上下文中调用
rethrow_nested()→ 抛出std::bad_exception - 嵌套多层后只展开一层，忽略更深层的
nested_exception→ 需递归处理
最小可行示例：
struct MyException : std::runtime_error, std::nested_exception {
MyException(const char* s) : std::runtime_error(s) {}
};
<p>try {
try {
throw std::logic_error("inner");
} catch (...) {
std::throw_with_nested(MyException("outer"));
}
} catch (const MyException& e) {
try {
e.rethrow_nested(); // 抛出 logic_error("inner")
} catch (const std::logic_error& inner) {
std::cout << inner.what(); // 输出 "inner"
}
}递归展开嵌套异常链需要手动控制深度和类型安全
C++ 标准没提供自动遍历异常链的接口，std::current_exception() 返回的是 std::exception_ptr，不能直接 downcast。所以“打印完整异常链”必须靠 try/catch + rethrow_nested() 循环实现，且每次重抛后需尝试匹配已知异常类型。
关键限制：
- 无法在运行时枚举嵌套层数，只能靠 catch 失败来判断是否到底
- 每层
rethrow_nested()后，必须用具体类型catch，否则会再次触发未处理异常终止程序 - 若某层嵌套异常不是继承自
std::nested_exception，则无法继续展开
实用技巧：把展开逻辑封装成函数，用 std::exception_ptr 避免多次抛出：
void print_exception(const std::exception_ptr& p, int level = 0) {
try {
if (p) std::rethrow_exception(p);
} catch (const std::nested_exception& e) {
std::cerr << std::string(level * 2, ' ') << "nested:\n";
print_exception(e.nested_ptr(), level + 1);
} catch (const std::exception& e) {
std::cerr << std::string(level * 2, ' ') << e.what() << '\n';
} catch (...) {
std::cerr << std::string(level * 2, ' ') << "[unknown exception]\n";
}
}调试时容易忽略 nested_exception 的 ABI 兼容性陷阱
异常链在跨动态库边界时极易断裂。即使两个模块都用同一版本 libstdc++/MSVCRT，只要异常对象内存布局不一致（比如一个编译时开了 -D_GLIBCXX_DEBUG，另一个没开），rethrow_nested() 就可能读到错位字段，导致段错误或静默跳过嵌套。
生产环境排查建议：
- 确认所有参与异常传播的模块使用完全相同的 STL 版本和编译选项
- 避免在 DLL / .so 接口函数中直接抛出带嵌套的异常；改用错误码 + 日志上下文
- 用
std::exception_ptr代替裸异常传递，它比异常对象本身更稳定
最隐蔽的问题：某些 sanitizer（如 ASan）会在异常栈展开过程中干扰 nested_ptr() 的内部指针，导致调试版能跑通、Release 版崩溃。遇到这类问题，优先检查构建一致性而非逻辑本身。
