主要观点：

• 曾写博客讨论“Hello World 中的错误”，许多编程语言默认输出到 stdout 会静默吞错，为此创建维护有该问题及修复示例的 repo。
• 以 C 语言为例给出修复后的 Hello World 代码，但该版本未考虑国际化等问题，且未调用fsync，简单命令行程序一般不期望fsync输出。
• 追溯到网络文件系统（NFS）时代，其设计导致同步 I/O 消息在网络上导致大量等待，引入“异步”模式后写错误会被延迟，最后write的错误在close时报告，而用户空间常不检查close的错误。
• 对于应用程序是否应检查close的错误存在争议，Linux 的close文档认为应检查，POSIX 的close文档则称close操作不必等待 I/O 完成，实际中很多应用程序不检查close的错误，且检查close错误还可能导致其他问题。
• 不仅应用程序开发者不知是否需检查close错误，还面临复杂问题，或许真正的问题在于系统设计，责任应在使用 NFS 或 FUSE 的人以及 I/O 错误的原因上。
• 如今网络文件系统不像过去那么流行，异步编程更方便的编程语言更受欢迎，难以要求应用程序开发者承担检查close错误的所有负担。

关键信息：

• 多种编程语言默认输出错误处理方式有问题及修复示例。
• NFS 时代及异步模式的特点和影响。
• 应用程序对close错误检查的争议及相关问题。
• 责任归属的讨论及现状。

重要细节：

• C 语言修复后的 Hello World 代码中通过fflush和ferror检查输出是否成功。
• NFS 异步模式下写错误延迟报告及close时报告最后write的错误。
• POSIX 和 Linux 对close的不同文档说明及实际应用情况。
• 检查close错误可能导致的如调试工具和 C++库的问题。
• 平台与应用程序在该问题上的僵持及现状。