据我所知,我处理流错误的两个选项是perror流异常.两种选择都是不可取的 原因如下:
PERROR
std::strerror返回实现定义的消息.此消息在所有系统上并不总是有用
std::strerror 不是线程安全的
返回的指针std::strerror可以无效
C库在技术上在C++中被"弃用".几乎总是有一个C++ - 等同于.当有潜在的C++等价物时,我没有理由不得不依赖POSIX和C.
流异常
例外并不适合每个计划
虽然std::strerror有时可以提供有用的错误消息,但流异常从不提供有用的错误消息.随着f.exceptions(f.failbit),对于未能打开文件或无法提取,抛出的异常是std::ios_base::failure和what()是" basic_ios::clear".
系统错误
更换std::ios_base::failure与std::system_error产生完全相同的结果.如果我们看看N2769: Detailed Reporting for Input/Output Library Errors (Revision 2),我们可以看到原因:
在抛出
ios_base::failure异常时,鼓励实现提供ec标识失败的具体原因的值.[ 注意 - 操作系统产生的错误通常会报告为system_category错误,错误值为操作系统报告的错误编号.流库中产生的错误通常会报告为error_code(ioerrc::stream, iostream_category) - 结束注释 ].上述措辞仅为规范性鼓励实施者做正确的事情,因此依赖于市场力量和实施者的良好内涵来产生对用户有用的结果.任何更强大的东西(例如改变"鼓励"到"应该")都需要更多的额外规范,并且超出了LWG可以为C++ 0x实际处理的范围.
另一种选择是可能依赖于庞大的第三方库(我正在看你Boost)或者手动滚动它(除非你知道你正在做什么,否则你永远不想做.)我正在寻找C++标准库的方式来做到这一点.有没有？