我正在编写一个与POCO C ++库动态链接的C ++库。我将POCO广泛用于某些方面，例如套接字，文件处理，日志记录等。因此，我需要处理POCO可能引发的异常。
除了与POCO相关的异常外，由于多种原因（基本上是运行时异常），我的代码还会引发其他异常。POCO C ++实际上包含一个RunTimeException类。因此，我可以使用它。
我的问题是：我是否应该仅依赖POCO异常，并允许使用我的库的第三方直接捕获它们？另一种选择是创建我自己的异常集，包装POCO异常并公开它们。这样，如果我决定将来摆脱POCO，则无需更改该部分。只是我包装的例外。
还有其他没有明显理由将所有POCO异常与我自己的包装在一起吗？
提前谢谢了。
这完全取决于您的库的实际用途（以及它在POCO上/旁边运行的抽象级别），以及为什么/如果您将POCO用作实现细节。（这里我忽略了是否应该在您的级别处理异常的问题，让我们假设这是从库的角度抛出异常的情况）
您无处可露该细节，并且通常不希望您图书馆的用户使用poco或根本不了解它。
在这里，您应该包装好自己的附件，或者如果您的标题中不包含poco标题，则可能完全用自己的例外替换它们。
在将来，您可能决定使用其他方法来实现您的库功能；传播POCO异常本质上就意味着对API进行了更改，否则就无需进行更改。
您的图书馆用户也应在其代码中使用POCO，而您只需添加一些内容，例如便利功能/语法
在这里，您可以假定您的库用户熟悉POCO及其异常，并且在捕获POCO异常方面没有问题，因为他们可能已经在其他地方了。
您极不可能在任何时候都不再使用POCO。
但是，您应该根据具体情况决定是否对用户查看POCO异常或您的异常有用。如果您只是一个瘦弱的包装者，并且很清楚正在使用什么底层POCO功能，那么仅传播POCO异常就足够了。
如果otoh所做的事情的功能与提供的任何标准POCO事情相去甚远，那么当人们看到POCO异常时，人们可能无法弄清楚到底出了什么问题。在这种情况下，包装可以提供其他信息，从而为您的库的用户提供有关库的抽象级别出了什么问题的更多信息。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句