我一直在研究一个读取XML文件的程序，如果ifstream无法打开该文件，它将抛出std :: ifstream :: failure。只要设置了std :: ifstream :: failbit或设置了std :: ifstream :: badbit，就会抛出此异常，并且（至少在我看来）它们是保证异常处理的错误类型。
打开文件后，我使用RapidXML创建DOM对象，如果失败，它的解析函数将抛出rapidxml :: parse_error。这种情况下错误并不是真正致命的 - 这只是糟糕的输入。无论如何，我认为当flashxml无法解析xml文件时抛出异常仍然是公平的，但即使我不这么认为，也没关系，因为我没有太多的选择。我可以关闭RapidXML中的异常，但是我仍然需要手动处理这些异常情况，并且通过异常机制处理它们要容易得多。然而，这绝对是一个阴暗的地方; rapidxml :: parse抛出异常的理由并不像ifstream那样明确。
最后一种情况是我正在解析DOM并遇到意外或意外的节点。很明显，程序可以在意外输入的情况下继续执行，但我不希望它。我可以想象在这里抛出异常，但我不确定这是否有意义。
所以，我要求一些建议：什么是异常处理的最佳实践？我尝试在类中使用RAII习惯用法，通过在构造函数中完成所有这些来解析文件。我使用boost :: shared_ptr来实例化文件解析类，所以如果构造函数抛出，boost :: shared_ptr将在删除文件解析类后重新生成std :: bad_alloc。
当XML文件不符合这个类所期望的内容时，我可以提出这个问题，并且我认为在出现意外输入时抛出异常是有意义的，但我真的很喜欢确保我的思维过程是正确的。
答案 0 :(得分：1)
您的设计对我来说很有意义：完全初始化或抛出异常。想到的唯一选择是：
对于全有或全无的方法，唯一的缺点是处理“几乎正确”的输入。如果缺少某个属性，应用程序可能更喜欢默认值。