我目前正在使用std::error_code
在出现问题时向我的API用户提供反馈。添加std::error_condition
类型warning
以通知我的用户存在小问题但是操作会继续进行是否在语义上可以接受?或者我应该只使用日志记录吗?
答案 0 :(得分: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)之类的东西确实使用非零结果代码&#39;成功或部分成功的条件......
此外,here诊断库的一位作者都声称&#34;该工具使用的约定为零意味着成功。&#34; 并且在同时使用error_code
来模拟HTTP错误(包括200
状态代码)。
这对error_code::operator bool()
的实际语义(标准中没有明确规定的含义)或标准诊断库对错误代码概念建模的有效能力提出了一些疑问。一般方式。 YMMV。
答案 1 :(得分:0)
库有几个选项可以告诉用户出现问题或与函数调用的内容不符。
您可以引入自己的错误数据结构(不要使用std::error_code
,因为它取决于操作系统)。
从库中杀死应用程序也不是很实用。即使它在库中是一个不可恢复的错误,它也不必对实际调用应用程序/进程/其他任何东西产生太大影响。让来电者决定做什么。
但所有这些都不适用。错误处理没有一个通用的解决方案。它可以非常具体到您的库的使用位置/方式/时间,因此您需要检查哪些适合您的目的以及调用约束必须/应该有多强。
在所有情况下都要明确调用者对错误处理的期望,并且不要让它感觉像是火箭科学。最小的设计在这里非常有用。