C++26 不包含 rethrow_with_context，它仍处于 TS 探索阶段；标准库不支持异常上下文是因值语义、零开销原则及跨 ABI 兼容性限制；当前可靠方案是手动包装异常并结合 std::source_location 与日志。
C++26 的 rethrow_with_context 提案（P2697R3）尚未被批准为标准特性，目前仍处于 TS 探索阶段，且不会出现在 C++26 中。它不是已定稿的 C++26 功能，而是 WG21 讨论中的一个实验性方向——目标是让异常在传播途中能自动附加上下文信息（如函数名、源码位置、局部变量快照等），从而改善调试体验。
为什么标准库至今不支持异常上下文？
C++ 异常对象本身是值语义的：抛出时复制/移动，捕获时绑定到 catch 参数。标准要求异常对象必须满足 CopyConstructible（或 C++11 后的 MoveConstructible），而任意“上下文”（比如栈帧快照、std::source_location 实例、甚至 std::string）会破坏零开销抽象原则，并引入隐式动态分配和 ABI 不稳定性。
更关键的是：异常可能跨 shared library 边界传播，而上下文数据的内存布局、生命周期、甚至 std::string 的实现细节（SSO vs 堆分配）在不同编译器/标准库间不兼容，导致 catch 侧访问损坏内存或崩溃。
std::exception_ptr 是唯一可移植的“异常转发”机制
如果你需要在异常传播链中插入诊断信息，目前最可靠的方式是手动包装：
- 用
std::make_exception_ptr捕获原始异常 - 构造一个自定义异常类型（如
contextual_error），在其构造函数中保存std::source_location::current()、关键变量值、以及原始std::exception_ptr - 在合适位置
throw这个新异常 - 下游
catch可递归调用std::rethrow_exception获取原始异常
struct contextual_error : std::runtime_error {
std::exception_ptr cause;
std::source_location loc;
contextual_error(const char* msg, std::exception_ptr p,
std::source_location l = std::source_location::current())
: std::runtime_error(msg), cause(std::move(p)), loc(l) {}
const char* what() const noexcept override {
return std::runt
ime_error::what();
}};
// 使用示例
try {
risky_operation();
} catch (...) {
auto ep = std::current_exception();
throw contextual_error("failed in process_user_data",
std::move(ep));
}
当前实际可用的诊断替代方案
不要依赖未落地的提案，优先采用已被广泛验证的手段：
ime_error::what();
}-
std::source_location（C++20）：在每个关键throw点显式记录位置，无需运行时开销 - 日志宏（如
LOG_ERROR("at {}:{}: {}", loc.file_name(), loc.line(), e.what())）：在catch块中立即输出上下文，比“重抛带上下文”更可控、无 ABI 风险 - 调试器集成：LLDB/GDB 支持
catch throw和bt查看完整栈，配合 DWARF 信息比运行时注入更准确 - 静态分析工具（如 clang-tidy 的
cppcoreguidelines-avoid-goto类规则）：提前发现异常路径中的资源泄漏点
C++ 对异常上下文的谨慎态度，本质是坚持“你不需要为不用的功能付费”。任何试图绕过这一原则的运行时机制，都会在跨模块、跨编译器、跨优化等级时暴露脆弱性。真正可靠的诊断，永远建立在明确控制权移交（catch → 日志 → 包装 → throw）和编译期可验证的信息（source_location）之上。
