文件I/O的故障修复策略
我正在将IO缓冲到一个文件中，既读又写。我使用的是fopen(), fseeko()，标准的ANSI文件I/O函数。在任何情况下，我都是在写入磁盘上的标准本地文件。这些文件I/O操作失败的频率有多大，失败的策略应该是什么？我并不是在确切地寻找统计数据，但我正在寻找一个通用的语句，说明我应该在多大程度上处理错误条件。
例如，我想每个人都认识到，malloc()有一天会在某个用户的机器上失败，开发人员应该检查是否返回空值，但是没有很好的补救策略，因为这可能意味着系统内存不足。至少，这似乎是malloc()在桌面系统上采用的方法，嵌入式系统是不同的。
同样，是否值得重新尝试文件I/O操作，或者我是否应该认为失败基本上是不可恢复的，等等。
我希望有一些代码示例演示正确的用法，或者提供一个库指南参考，说明如何处理这个问题。当然，任何其他数据都是受欢迎的。
回答 2
Stack Overflow用户
发布于 2013-11-03 21:53:06
我猜你是这里的新手程序员。我在这里给出的建议并不适用于所有情况，但它将帮助您编写可靠的代码。
- 试图找出如何从错误中恢复是很困难的，除非您有一个非常可靠的模型来说明错误是如何发生的以及它意味着什么。
- 因此，除非您确切地知道错误是什么以及它意味着什么，否则请在
stderr或whathaveyou上报告错误，然后删除。 - 如果第一件事出了差错，你就会被迫理解错误并修复代码。从长远来看，这将导致更高质量的代码，即使你的直觉表明情况并非如此。
- 一些函数返回不表示严重故障的“错误”。在POSIX中，
EINTR作为一种黑客，使信号处理更容易实现，它的副作用是使关心信号的单线程程序的体系结构变得更容易实现。当I/O函数返回EAGAIN时，这意味着文件以非阻塞模式打开，I/O需要阻塞。你需要正确处理这些事情。 - 一些错误表明发生了一些可怕的事情；POSIX中的
EIO意味着发生了一些错误，函数甚至不知道如何讨论。 - 使用文件系统代码时，您会注意到对文件的并发更新可能会导致一些错误。尝试“优雅地”从这类事情中“恢复”是一件愚蠢的事。别试。
Stack Overflow用户
发布于 2013-11-03 21:59:53
这是我的一份被否决的答复，试图给它另一次机会。
这在很大程度上取决于程序的类型。
作为一个突出的例子，Glib，一个流行的C库不关心处理OOM；它只是中止。这可能适用于应用程序代码，但并不适用于某些系统级别的代码。
在大多数情况下，I/O错误或OOM的情况可以被认为是不可避免的。例如，许多遇到OOM的程序都有非常连续的(几个分支)代码页，并且在失败的分配中没有其他选择。因此，大多数程序只会退出(1)。
如果你在另一边操纵合理的状态，你应该尽你最大的努力避免崩溃或退出。
但清理工作往往很困难，特别是在C平原。
作为一个合理的最低限度，您应该始终尝试调查失败的直接原因，并将其打印到stderr --这有助于调试。
我可以推荐阅读reprepro的源代码，它在处理错误条件和清理时非常小心。这是一个大量的锅炉板，所以你可能会选择它不适合你的应用程序后，阅读。
https://stackoverflow.com/questions/19758483
复制相似问题
腾讯云开发者
