Question

我的老板告诉我要查看一些旧代码，其中所有内容都发送给stderr。我知道stderr应该有警告和错误，但他们什么时候应该去stdout呢？

此计划是一项服务。它发送给stderr的一些消息是：

if pid is None:
    message = "pidfile {0} is not running. \n"
    sys.stderr.write(message.format(self.pidfile))

所以这个是输出，对吗？关于成功与否的信息应该转到stdout，因为它不是错误？

然后我得到另一个例外：

except OSError as err:
    sys.stderr.write('fork #1 failed: {0}\n'.format(err))
    sys.exit(1)

这个作为例外，所以它应该去stderr，因为它是一个错误？或者它应该转到stdout，因为它只是说程序失败的输出消息？

我知道stdout和stderr是什么 - 在我问之前我读了很多。我的问题是能够识别哪些消息应该发送到stderr ---只是致命错误或任何类型的错误消息？

这两个示例都是错误消息，但其中一个只是＆＃34;程序未运行＆＃34;。我在选择应该发送哪种邮件时遇到问题。

Answer 1

致命错误当然应该发给stderr。正常输出应该转到stdout。

信息性消息有一个灰色区域，但一般来说，如果它们使输出无法使用，它们不应该转到stdout。人们经常会将stdout指向文件，并将stderr指向终端或日志文件。

您需要确定哪个部门最有意义。

Answer 2

Tom Karzes 已经给了你一个正确的答案，但要表明一个更极端的立场......

我发现将stdout和stderr视为“标准输出”和“标准非输出”会有所帮助。你说你认为一条消息“应该转到stdout，因为它不是错误”，但那是向后的： stdout 是具有较高进入门槛的流，而不是{ {1}}。

消息应该转到stderr（或日志文件，或除stderr之外的任何内容），除非它可以证明是所需输出的一部分 - 用户实际上的最终产品希望。如果你不能证明它包含一个开头的句子，“用户要求......”，不用它来污染stdout。（管道中的下一个过程将感谢你。）

可能的情况是，您的用户没有运行您的程序，因为他们想要观看旋转的指挥棒，或者阅读十几个“尝试重新连接...”消息，甚至了解哪些叉子失败了，所以那些应该不在stdout。

最后，有些消息不应该转到输出流。 stdout可能是由用户阅读，因此请尝试将其输出限制为用户关心现在的内容。保持它没有“正常情况”消息，除非用户通过提高详细程度（通常为stderr或--verbose）专门请求它们。至少允许用户使用--debug或--quiet选项来消除非错误。大多数“信息性”消息应该发送到日志文件而不是控制台。

何时使用sys.stdout而不是sys.stderr？

2 个答案: