0

我目前std::error_code用来在出现问题时向我的 API 用户提供反馈。std::error_condition添加一个of 类型warning来通知我的用户存在一个小问题但操作将继续在语义上是否可以接受？还是我应该只为此使用日志记录？

4

2 回答 2

2

如果我理解正确，您会问是否应将返回警告视为滥用std::error_code语义。

现在，该标准error_code作为标准诊断库的一部分引入

[diagnostics.general]本条款描述了 C++ 程序可用于检测和报告错误情况的组件。

而且，据我所知，对“错误条件”是什么没有语义要求，我们可以假设这些是用来报告出现问题的，但它似乎并没有强加部分的影响一个操作规范的履行应该是，操作应该告诉你的。

我看到的唯一语义要求是 error_code（和 error_condition）是布尔可转换的，也就是说，“零”错误代码应该总是意味着成功。

现在，假设您希望完成带有警告的操作被认为是成功的，因此我认为通过错误代码返回这样的警告是无效的；也就是说，您可能总是让您的操作返回两个错误代码（以您喜欢的方式，可能属于不同的类别），记录只有第一个报告操作效果的实现：

auto [err,war] = some_operation();

if(err) call_the police(); // some_operation failed
else if(war) // some_operation complains
{
  std::cerr << "hold breath...";

  if( war == some_error_condition )
    thats_unacceptable();

  //else ignore
}

也就是说，请注意存在与我上面的推理不同的实际用例；事实上，像 HTTP 结果代码和库（如 Vulkan）之类的东西确实使用非零“结果代码”来表示成功或部分成功的条件......

此外，这里的诊断库的作者之一都声称“该设施使用零表示成功的约定”。同时用于error_code对 HTTP 错误进行建模（200包括状态码）。

这使人们对实际语义error_code::operator bool()（其含义未在标准中明确阐述）或标准诊断库以一般方式对错误代码概念建模的有效能力产生一些疑问。YMMV。

于 2017-12-01T15:17:40.863 回答
-1

库有几个选项可以告诉用户出现问题或与函数调用的预期不符。

  • 例外。但是有异常开销，try/catch ...
  • 升压/标准：：可选。如果出现错误/警告，您可以将其作为返回值（输入/输出或输出参数）发出，否则可选值为 false
  • 标准::对/标准::元组。这样，您可以在返回值中编码更多信息（尽管自定义结构也可能更明确地做到这一点）

您可以引入自己的错误数据结构（不要使用std::error_code，因为它取决于操作系统）。

从库中杀死应用程序也不是很实用。即使它是库中不可恢复的错误，它也不必对实际调用应用程序/进程/任何内容产生太大影响。让调用者决定做什么。

但所有这些并不普遍适用。错误处理没有万能的解决方案。它可能非常具体到使用库的位置/方式/时间，因此您想检查什么适合您的目的以及调用约束必须/应该有多强。

在所有情况下，都要清楚调用者可以从你的错误处理中得到什么，不要让它感觉像火箭科学。最小化的设计在这里非常有帮助。

于 2017-12-01T13:47:09.077 回答