C++11(或Boost)system_error策略

2024-03-28

我正在开发一个系统,该系统旨在使用名为的类error_code, error_condition, and error_category-- C++11 中新的 std: 方案,尽管目前我实际上正在使用 Boost 实现。我读过克里斯·科尔科夫的系列文章 http://blog.think-async.com/2010/04/system-error-support-in-c0x-part-1.html,现在已经三遍了,我想我大致了解了如何创建这些类。

我的问题是这个系统需要处理单独 DLL 中存在的插件,并且插件可能会发出错误。我最初的设计是规划一个特定于系统的错误类别,其中包含所有各种错误代码和一份特定错误条件的候选列表,这些错误条件并不真正映射到errno价值观。这里的问题是,为了使 DLL 能够使用这些错误代码之一,它需要访问该错误代码的唯一实例。error_category在应用程序中。我现在通过导出来处理这个问题SetErrorCategory()每个 DLL 中都有一个函数,它可以工作,但有点令人讨厌。

我看到的替代解决方案是每个 DLL 都有自己的错误类别和代码,如果需要的话,还有自己的条件;我怀疑这更像是这个库功能的设想。但是,我认为这需要主应用程序的错误方案中的比较函数,该函数了解插件的错误方案,并可以检查应用程序的哪些条件与插件的错误匹配。尽管我还没有尝试实现它,但这似乎更容易出现一堆问题。我猜想我必须从 DLL 中导出整个错误方案(在所有实际逻辑之上)。

当然,另一种方法是使用 DLL 中的数字错误代码并将它们填充到应用程序端的错误对象中。它的优点是插件简单,但可能会导致应用程序出现问题(例如,处理来自几个不同插件的对象的函数需要注意每个错误的来源)。

所以我的具体问题是:在这三个选项中,您会使用哪个,为什么?哪个显然是行不通的?当然,还有我没有想到的更好的方法吗?


我在解决这个问题时得出的解决方案是使用预定义的代码来处理问题系列和用户子代码选择以及特定类型错误的继承。通过 boost,我可以通过以下方式继承特定类型:

struct IOException : virtual std::exception, virtual boost::exception {};
struct EOFException : IOException {};
...

并保留与预定义的一般错误(例如 IOException)相匹配的错误代码。因此,我可以为每个错误系列提供一个通用代码范围:

namespace exception { namespace code {
    UNKNOWN_EXCEPTION           = 0;
    IO_EXCEPTION                = 100;
    CONCURRENCY_EXCEPTION       = 200;
    ...
}}

然后,如果有人想要新的错误类型,他们可以从已定义的通用异常类型以及与该错误相关的代码继承,并通过继承类型和次要值 (0-99) 专门化异常。这还允许 try catch 块捕获更具体的错误类型,同时让更通用的异常版本传递到其他控制块。然后,用户可以自由使用父异常代码或指定属于该系列的自己的代码(父= 100 -> 子= 115)。如果用户只想要 IOError,而不创建新的错误系列,他们可以轻松使用默认的异常系列。我发现这为用户提供了灵活性,而无需在他们不需要时强制跟踪异常代码。

然而,这绝不是最终的解决方案,因为个人喜好主导了我的设计选择。我发现错误代码太多会变得混乱,并且异常继承已经编码了这些信息。实际上,在我描述的系统中,很容易完全删除错误代码并仅依赖异常继承,但许多人更喜欢为每个异常名称分配一个代码。

本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)

C++11(或Boost)system_error策略 的相关文章

随机推荐