ostream::write 或 ostream::operator<< 在什么情况下会失败？答案

【问题标题】：What circumstances ostream::write or ostream::operator<< would fail under?ostream::write 或 ostream::operator<< 在什么情况下会失败？
【发布时间】：2013-05-17 03:14:53
【问题描述】：

在我的 C++ 代码中，我不断将不同的值写入文件。我的问题是，考虑到文件已成功打开的事实，如果在任何情况下 write 或

【问题讨论】：

硬盘坏了怎么办？
这是我唯一能想到的。

标签： c++ file ofstream ostream

【解决方案1】：

失败的原因太多了，无法一一列举。可能的有：

分区终于满了
用户超出了他的磁盘配额
分区已被粗暴地卸载
分区已损坏（文件系统错误）
磁盘发生物理故障
...

我是否需要检查每一个 write 或

如果您希望您的程序能够适应故障，那么，绝对是，是的。如果你不这样做，它只是意味着你正在写入的数据可能会或可能不会被写入，这等于说你不关心它。

注意：您可以根据自己的喜好设置std::ostream::exceptions，而不是在每次操作后检查流状态（这很快就会变得非常乏味），这样流在失败时会抛出异常（这应该不是问题，因为根据定义，此类磁盘故障是非常特殊的）。

【讨论】：

我想我要控制每一个 write 调用。
@ipluto：查看我的编辑以避免“手动”检查每个调用。我相信在这种情况下，例外是正确的工具。

【解决方案2】：

写入失败的原因有很多。以下是我脑海中的一些：

磁盘已满
磁盘出现故障
文件在 NFS 挂载上，网络出现故障
您正在写入的流（请记住，ostream 并不总是文件）恰好是在下游读取器崩溃时关闭的管道
您正在写入的流是 TCP 套接字，而对等点消失了

等等。

编辑：我知道您说过您正在写入文件，我只是想提请注意这样一个事实，即您的代码应该只关心它正在写入可能的 ostream代表任何类型的流。

【讨论】：

谢谢，特别是提到不相关的文件条件。

【解决方案3】：

其他涵盖了可能导致输出失败的情况。

但是：

我是否需要检查每一个 write 或

对此，我会回答“不”。可以想象你也可以检查一下

如果文件打开成功，并且
如果在您写入数据后流仍然是good()。

这当然取决于写入的数据类型，以及从部分写入恢复与重新运行应用程序的可能性/相对复杂性。

如果您需要更严格地控制写入失败的确切时间（例如，为了进行正常恢复），则可以使用 sym 链接到的 ostream 异常。每次操作后轮询流状态会使代码膨胀。

【讨论】：

+1，如果数据不是太关键，延迟检查确实是有意义的（我猜被用来处理关键数据让我对这种松散检查的可能性视而不见）。
@syam：请参阅——在我正在使用的应用程序中，部分写入没有意义，并且不可能进行有意义的恢复。就我而言，要么全有，要么全无。我什至不知道让ostream 立即成为例外的可能性，如果我需要它，那对我来说是一个很好的胜利。 ;-)
我最近的项目完全相反，我需要（几乎）实时存储传入数据并尽可能减少丢失风险（因此我渴望检查每一次写入）。无论如何，很高兴我的回答对你有用。
@syam: ...所以你不仅要小心设置ostream::exceptions，还要禁用缓冲，我猜？我对 C 语言的 setvbuf() / _IONBF 很熟悉，但不太清楚如何使用 C++ 流实现无缓冲 I/O。你介意在我们讨论的时候把这个花絮也扔给我吗？ ;-)
Posted new question.