重新包装异常，还是保持它们完好无损？答案

【问题标题】：repackaging exceptions, or keep them intact?重新包装异常，还是保持它们完好无损？
【发布时间】：2011-10-14 13:45:40
【问题描述】：

我正在编写一些具有 2 个（主）子系统的类。一部分依赖于 boost::filesystem 而另一部分依赖于 tinyxml。（基本上，它读取一个 xml，并根据 xml 的数据使用boost::filesystem 的函数来更多地访问其他文件）。

现在这两个都“可能”抛出异常。我想知道如何处理这些异常：

类本身 - 在大多数情况下 - 无法“修复”异常，只能将其扔回。（最可能的情况是用户输入错误）。

但是在这种情况下应该怎么做呢？ - boost::filesystem 和 tinyxml 都有自己的异常，彼此并不完全兼容。

我应该只期望这个类的用户处理 boost/tinyxml 异常吗？ - 到目前为止，这些库的全部使用对最终用户是隐藏的。

我应该将扩展重新打包成我自己的吗？我总是对重新打包犹豫不决，因为这意味着需要大量额外的 try ... catch 块。

你有什么推荐给我的？

【问题讨论】：

""likely""，用引号括起来吗？你什么意思？代码是否允许抛出异常？ Here is a previous answer 我的主题。
我的意思可能是：发生异常是有充分理由的：磁盘可能被写保护，输入路径可能有问题，可能存在损坏的文件等。这些事情可能会发生因此，很多不应成为整个应用程序崩溃的原因。

【解决方案1】：

如果不了解您的代码和编码指南，尤其是与异常相关的内容，就不可能回答这个问题。

但是，如果您的编码指南允许例外，那么我建议采用一般的经验法则：

允许异常传播，直到它们到达可以正确处理的上下文。如果它们从未达到可以正确处理的上下文，则允许您的程序崩溃。获取核心转储并调试问题。

在特定上下文中“处理”异常可能就像将其转换为错误代码或您自己的异常类一样简单，但在这种情况下，您应该重新抛出新异常并允许它传播到处理程序。

不要为了防止您的应用程序崩溃，甚至记录错误并终止，而对异常实施任何形式的包罗万象的处理程序。相反，实现一个系统，该系统将在发生未处理的异常时生成转储，并让你的程序死掉。转储本身就足够了一个日志。您不希望万能，因为您的系统处于损坏状态，无法从中恢复。

【讨论】：

该程序的主要目标（目前）是处理（合并、拆分）一些“特定”的 xml 文件。最终用户将提供主 xml 文件 -> tinyxml 在提供不存在的文件时可能会崩溃。 xml 文件将包含指向其他文件的链接 -> boost::filesystem 用于处理此问题并可能崩溃。

【解决方案2】：

我建议您的课程抛出您自己的异常。通过这种方式，您可以强制执行信息隐藏，并且您的类客户端不会依赖于您决定使用的库。

【讨论】：

【解决方案3】：

您认为它与最终用户相关吗？因为这和设计有关。

有些库在windows上使用时有自己的数据，而您可以使用其他错误处理方法进行验证。例如，sqlite 有自己的一组错误代码，但您可以使用 GetLastError 来了解数据库未打开的原因。

就您而言，问题是：您会在自己的班级中使用异常吗？在这种情况下，最好提供您自己的异常。如果没有，您可以允许用户缓存您的错误和异常（如果他愿意）。

克劳迪奥。

【讨论】：

"如果没有，您可以允许用户缓存您的错误和异常，如果他愿意的话。" - 你的意思是什么？
好吧，有些 API 像 Windows API 不适用于异常（Win32 API）。 API 的用户可以决定是否处理这些错误（例如，使用 GetLastError 或返回值）。