重新打包异常，还是保持原样？

Question

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

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

在大多数情况下，类本身不能“修复”异常，只能将其抛弃。 （最可能的情况是来自用户的错误输入）。

然而，在这种情况下应该怎么做？ - boost::filesystem＆amp; tinyxml都有自己的异常，这些异常并不完全相互兼容。

我应该期望这个类的用户处理boost / tinyxml异常吗？ - 到目前为止，最终用户隐藏了这些库的整个用法。

我应该将扩展名重新打包到我自己的扩展名中吗？我总是对重新包装犹豫不决，因为这意味着需要进行大量的尝试......捕获块。

你推荐我什么？

Answer 1

我建议你的班级抛出你自己的例外。这样，您就可以强制执行信息隐藏，而您的类客户端将不依赖于您决定使用的库。

Answer 2

如果不了解您的代码和编码指南，则无法回答这个问题，特别是因为它们与例外有关。

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

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

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

不要为异常实现任何形式的catch-all处理程序，以防止应用程序崩溃，甚至记录错误和死亡。相反，实现一个系统，该系统将在未处理的异常情况下生成转储，并让您的程序死亡。转储本身就足够了。你不想要一个全能，因为你的系统处于一个无法恢复的腐败状态。

Answer 3

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

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

在您的情况下，问题是：您是否会在自己的班级中使用例外？在这种情况下，它更好地提供您自己的例外。如果没有，您可以允许用户根据需要缓存您的错误和异常。

克劳迪奥。