因此，在我了解std::error_code如何运作的旅程中，我开始怀疑我们是否真的需要std::error_condition和std::error_category。我试图实现this和this教程中的内容，并且工作量并非易碎，而且相当脆弱（我目前一直在试图弄清楚为什么此代码会导致链接错误与重复符号有关。我们真的需要std :: error_category和std :: error_condition吗？
是不是更容易继承std::error_code，加message财产&方法，然后让std::error_code相媲美，其中错误代码定义枚举？我挣扎理解为什么我需要std::error_category和std::error_condition可言。
主要优点是error_code是可复制的类型，可以从图书馆到图书馆wi不必涉及任何动态内存分配或模板，使其非常轻便，并且易于使用。
如果你正在编写一个完全独立的项目，那么是的，当你只有自己的类型时，错误代码和类别似乎过于复杂。
但是，编写一个图书馆意味着要被其他人使用时（比如ASIO，因为你链接了think-async.com），事情就会改变。您可以让一个库接收一个error_code实例，并且它可以干净而高效地传递它，而无需了解使用该库的代码的任何内容，或者必须使每个错误处理函数都在错误上进行模板化类型。
在这种情况下，错误类别在处理多个错误源时很重要，因为给定的错误代码可能意味着基于错误来源的两种不同的事情。
编辑：请注意，在您的第一个链接，类别实际上是单身人士。这是在保持轻量级的服务中完成的，因为将指针复制到保证永不被删除或修改的对象是便宜的，内存安全的和线程安全的。
我想补充一点，它也可以很容易地通过像std :: system_error这样的标准异常类型传输自定义错误代码。使用您的库的客户端代码不需要知道有关您的自定义错误类别的任何信息。他们可以通过调用'std :: error_code'的* generic *方法来捕获'std :: system_error'，他们可以将它写入日志文件，其中错误值，您定义的错误类别的名称以及将显示您在错误类别中定义的字符串消息。比输出“错误代码123”好得多，在这里没有人知道它属于哪个上下文。 – zett42
在C++中有多种处理错误的方法，没有一种真正的方法。如果你不需要它，不要使用它。 –