c++ - 除了 what() 之外，C++ 异常是否应该提供额外的细节？

Question

除了 what() 之外，我的异常类是否应该在公共(public)字段中提供详细信息？

考虑例如 boost::property_tree::ptree_bad_path 可能会给出一条消息:

"No such node (mynode.value1)"

访问路径 ("mynode.value1") 的唯一方法是解析字符串。是否有人反对添加额外的公共(public)字段来携带此类信息，即:

class ptree_bad_path : public ptree_error {
public:
  const std::string path; // <- additional detail by public field
....

这种方法有缺点吗？

Answer 1

理论上，如果您同时遇到两个未处理的异常，您将面临让程序终止 的风险。然而，这是一种相当罕见的情况。

• 在准备异常期间抛出:很好(尽管您不会得到预期的异常)
• 在异常复制期间抛出(通常被省略，可避免):崩溃
• 展开时抛出:crash
• 在异常处理期间抛出 (catch):很好(毕竟，重新抛出不同的异常很常见)

因此，这里可以避免的风险是，如果您的异常的复制构造函数可能碰巧抛出。通过将状态移到异常中包含的 shared_ptr 来避免这个问题是微不足道的。它使拷贝有点“特殊”(因为它们与原件共享它们的状态)但如果它被正确记录，它不应该引起任何悲伤。

更大的风险是在堆栈展开期间。不过，它仅在析构函数抛出时才会发生。

就我个人而言，我使用的异常包括:

• 一个错误代码(为了让 API 正确显示/编码，所有错误消息都映射到一个代码，这对中文/韩文/日文很有帮助，真的)
• 一条日志消息，包含一些详细信息(导致问题的项目的 ID/名称、翻译另一个异常时的原始错误，无论有什么帮助!)
• 抛出异常的函数/文件/行
• 抛出异常的时间
• 附加说明(在堆栈展开期间“即时”附加)
• 完整的回溯(使用 Linux 特定函数)

这里唯一有争议的一点是 on the fly 位，因为它实际上可能会崩溃。另一方面，我在服务器上工作，所以崩溃很容易(并且紧急)修复，在过去的 5 年里，我非常小心，没有导致崩溃(这样 ;))。

请注意，此方案显然仅在您稀疏地使用异常时才可用。如果您经常为每个任务抛出十几个异常，则性能可能无法接受。另一方面，主要编译器使用的零成本模型已经严厉地惩罚了异常路径，因此...