为什么我们总是检查输入是否失败而不检查输出

在输入时生成文件结尾很容易。例如，输入可能来自一个文件。或者，交互式用户可能会以某种特定于命令解释器的方式指示EOF(例如，Windows中的Ctrl Z或*nix中的Ctrl D)。

通常会导致输入失败。

对于格式化输入的cin >> var，也可能无法将输入文本解释为相关类型的值的规范。

这些都不适用于输出。

输出可能会失败，但通常只是由于相当灾难性的原因，例如存储单元已满。

前提是错误的：并不是所有的写入都是未检查的。

作为检查写入的示例，请考虑一个数据库。在对提交请求回答OK之前，数据库通常会确保数据已正确写入磁盘或复制(并确认)到另一个实例。

因此，软件很少检查写入，而更多的是以不同于读取的方式检查写入：读取失败意味着程序无法继续(通常)，因为它缺乏数据；另一方面，程序可以在失败后继续写入，因为它已经有了数据！

因此，唯一被检查的写入是程序保证检查的写入，例如数据库写入硬盘，以确保软件承诺的数据的持久性。另一方面，很少(如果有的话)检查对日志文件或控制台屏幕的写入：日志文件通常不会妨碍(并且它们是异步记录的)，如果对控制台屏幕的写操作失败，用户可能无论如何都会重播命令，或者管道中的下一个程序本身也会失败。。。

输入是程序无法控制的。

例如，人类打字不那么准确。因此，你可以让程序采取步骤，要么让用户再次尝试，等等。

至于输出，您可以检查。但对人类来说，出了什么问题是不言而喻的。当写入文件但输出到屏幕时，情况并非如此。如果你不能将输出写入控制台，你能做什么？