c++ - 错误处理 : distinguishing between 'fatal' errors and 'unexpected input' errors

Question

我一直在开发一个读取 XML 文件的程序，如果 ifstream 无法打开该文件，它将抛出 std::ifstream::failure。每当设置 std::ifstream::failbit 或设置 std::ifstream::badbit 时都会抛出此异常，并且它们是(至少在我看来)保证异常处理的错误类型。

打开文件后，我使用RapidXML创建DOM对象，它的parse函数如果失败会抛出rapidxml::parse_error。在这种情况下，错误并不是真正致命的——它只是错误的输入。无论如何，我认为 rapidxml 在解析 xml 文件失败时抛出异常仍然是公平的，但即使我不这么认为，也没关系，因为我没有太多选择.我可以关闭 RapidXML 中的异常，但我仍然必须手动处理这些异常情况，而且通过异常机制处理它们要容易得多。但是，这绝对是一个模糊的区域。 rapidxml::parse 抛出异常的理由并不像 ifstream 那样明确。

最后一种情况是当我解析 DOM 时遇到一个意想不到的或未预料到的节点。显然，程序可以在意外输入的情况下继续执行，但我不希望它这样做。我可以想象在这里抛出一个异常，但我不确定这是否有意义。

所以，我想寻求一点建议:异常处理的最佳实践是什么？我尝试在通过在构造函数中执行所有这些操作来解析文件的类中使用 RAII 习惯用法。我使用 boost::shared_ptr 来实例化文件解析类，因此如果构造函数抛出异常，boost::shared_ptr 将在删除文件解析类后重新抛出 std::bad_alloc。

当 XML 文件不符合此类的预期时，我可以提出让这种情况发生的论据，而且我认为在出现意外输入时抛出异常是有意义的，但我真的只是喜欢以确保我的思维过程是正确的。

Answer 1

您的设计对我来说很有意义:完全初始化或抛出异常。想到的唯一选择是:

• 状态代码
• 尽最大努力使用状态成员函数进行初始化，以找出哪些部分有效

唯一想到的全有或全无方法的缺点是处理“几乎正确”的输入。如果缺少某个属性，应用程序可能更喜欢默认值。