std::exception_ptr 不能直接打印嵌套原因,它仅保存异常快照,需手动 rethrow 才能访问 what(),但会丢失上下文;正确做法是在捕获点主动拼接上下文字符串。

std::exception_ptr 能不能直接打印嵌套原因?
不能。它只是异常对象的“快照”,不自带消息格式化能力,更不会自动展开嵌套链。你拿到 std::exception_ptr 后,必须手动 std::rethrow_exception 才能访问原始异常类型和 what(),但一重抛就丢失上层上下文。
常见错误现象:只捕获并保存 std::current_exception(),然后在日志里直接输出 ptr.get() 地址——这等于什么都没报。
- 真正要带上下文,得在捕获点主动拼接字符串,比如:
"[DB layer] failed to commit transaction: " + e.what() - 如果用
std::nested_exception(C++11 起),需确保派生类显式调用std::throw_with_nested,否则嵌套关系不会建立 -
std::nested_exception本身没有what(),必须配合dynamic_cast到具体类型再取消息
std::error_code 和 std::error_condition 怎么避免语义混淆?
它们不是用来替代异常的,而是为“可预期、可恢复”的系统级错误设计的,比如文件不存在、权限不足、网络超时。混用会导致错误分类失焦:把本该中断流程的逻辑错误(如空指针解引用)塞进 std::error_code,后续调用方可能误判为可重试。
使用场景明确:仅用于 POSIX 错误码、Windows GetLastError() 映射、或自定义枚举错误域(std::error_category 子类)。
立即学习“C++免费学习笔记(深入)”;
-
std::error_code是值类型,含具体错误值 + 对应 category;std::error_condition是逻辑抽象,比如std::errc::no_such_file_or_directory - 比较时用
error_code.value() == errc::invalid_argument不可靠,应走error_code.category() == std::generic_category()再比值,或直接用error_code == std::errc::...(已重载) - 不要把
std::error_code当异常抛出——它没栈回溯,也没嵌套支持,日志里只剩一个数字
手写带上下文的 Error 类,哪些字段不能少?
至少得有三块:原始错误信息(来自 what() 或 error_code.message())、发生位置(__FILE__、__LINE__、可选函数名)、上下文描述(调用方传入的字符串,比如 "while parsing config file 'app.json'")。缺任意一块,排查时就得来回翻代码猜。
性能影响很小,但要注意:文件路径字符串别存裸 char*,得拷贝;若用 std::string_view,确保源字符串生命周期长于 Error 对象。
- 构造函数建议接受
const std::exception&+std::string_view context,内部调用e.what()并拼接 - 避免在
what()里做动态分配(如std::ostringstream),否则可能在栈展开中途抛新异常导致std::terminate - 如果项目用 C++17 或更新,可加
[[nodiscard]]提示调用方别忽略返回的 Error 对象
第三方库如 Outcome 或 Boost.Outcome-V2 值不值得引入?
值得,但只在已有大量同步 I/O 或系统调用且错误处理分散的模块里引入。它们把 error_code 和结果值绑在一起,强制调用方处理错误分支,天然抑制“忽略返回值”问题。
容易踩的坑是过度设计:给纯内存计算函数(比如矩阵乘法)也套 result<t></t>,反而让接口变重、编译变慢、调试更难——这类错误本该用断言或异常。
- Outcome 的
result<t e></t>默认移动语义安全,但若E是大对象(比如含堆内存的自定义 error 类),要考虑std::move开销 - Boost.Outcome-V2 支持
std::exception_ptr作为错误类型,可桥接传统异常体系,但会增加二进制大小 - 别指望它们自动补全调用栈——仍需手动注入
__FILE__/__LINE__,或配合boost::stacktrace
复杂点在于:上下文不是靠某个机制自动附着的,得靠每个捕获点、每层包装函数主动传递。漏掉一层,日志就断一节。这个动作没法自动化,只能靠规范和 Code Review 卡住。









