3

我正在将缓冲 IO 写入文件，包括读取和写入。我正在使用fopen(), fseeko()标准 ANSI C 文件 I/O 函数。在所有情况下，我都在写入磁盘上的标准本地文件。这些文件 I/O 操作多久失败一次，失败的策略应该是什么？我并不是在寻找统计数据，而是在寻找关于我应该在多大程度上处理错误情况的通用声明。

例如，我认为每个人都认识到malloc()某天在某些用户的机器上可能并且很可能会失败，开发人员应该检查是否返回了 NULL，但是没有很好的补救策略，因为这可能意味着系统内存不足。至少，这似乎是malloc()在桌面系统上采用的方法，嵌入式系统是不同的。

同样，是否值得重新尝试文件 I/O 操作，或者我是否应该认为故障基本上是不可恢复的，等等。

我将不胜感激一些演示正确用法的代码示例，或指示如何处理的库指南参考。当然，欢迎任何其他数据。

4

2 回答 2

1

我猜你是这里的新手程序员。我在这里给出的建议并不适用于所有情况，但它会帮助你编写可靠的代码。

  • 试图弄清楚如何从错误中恢复是很困难的，除非你有一个非常可靠的模型来说明错误是如何发生的以及它意味着什么。
  • 因此，除非您确切地知道错误是什么以及它的含义，否则请报告错误stderr或您有什么并轰炸。
  • 如果您在第一件事出错时立即轰炸，您将被迫理解错误并修复您的代码。从长远来看，这会导致更高质量的代码，即使您的直觉表明并非如此。
  • 一些函数返回不表示严重故障的“错误”。在 POSIX 中，EINTR是否存在使信号处理更易于实现的 hack，并且它具有使关心信号的某种单线程程序架构更易于实现的副作用。当 I/O 函数返回EAGAIN时，这意味着您以非阻塞模式打开文件并且 I/O 想要阻塞。你需要正确处理这些事情。
  • 一些错误表明发生了可怕的事情；EIO在 POSIX 中意味着出现了问题，该函数甚至不知道如何谈论。
  • 使用文件系统代码，您会注意到一些错误可能是由文件的并发更新引起的。试图“优雅地”从这些事情中“恢复”是愚蠢的差事。不要尝试。
于 2013-11-03T21:53:06.390 回答
0

这是我的快速投票答案的副本，试图再给它一次机会。

这在很大程度上取决于程序的类型。

作为一个突出的例子，流行的 C 库 Glib 不关心处理 OOM。它只是中止。这可能适用于应用程序代码，但不适用于某些系统级代码。

在大多数情况下，可以假定 I/O 错误或 OOM 等情况是不可避免的。例如，许多遇到 OOM 的程序都有非常连续的（很少分支）代码路径，并且在分配失败时没有替代方案。因此，大多数程序只会退出（1）。

如果你在另一边正在操纵合理的状态，你应该尽量不要崩溃或退出。

但清理通常很困难，尤其是在纯 C 语言中。

作为一个明智的最低限度，您应该始终尝试调查失败的直接原因并将其打印到 stderr——它有助于调试。

我可以推荐阅读 reprepro 的源代码，它在处理错误情况和清理时非常小心。这是大量的样板，因此您可能会在阅读后选择它不适合您的应用程序。

于 2013-11-03T21:59:53.377 回答