这是一个基本问题，但我找不到合适的答案。
例如，如果我使用malloc，我会检查malloc，如果我看到错误，我可以这样做：
fprintf(stderr, "Message");
这是一条重要的错误消息，输出位于stderr。
现在，如果我有一个程序在1和5之间询问数字。程序会询问用户，直到他输入一个好的数字。
如果用户输入10，例如，重定向到stderr的错误消息是否有用？
fprintf(stderr, "Message, wrong number, try again");
或者它是正常错误，该消息应该在stdout上？
答案 0 :(得分：3)
如果您希望独立于所有其他输出重定向某些类型的错误，请将其发送至stderr。
否则，我认为在整个计划中保持一致非常重要，因此请确定哪些内容在哪里并坚持下去。
答案 1 :(得分：2)
由您决定如何以及何时使用它。
一个常见的应用程序是将程序输出与不属于输出的任何类型的通知分开，无论是错误还是只是进度，以便用户知道程序没有挂起或任何东西。
例如，我有一个代码，它从Web服务器获取XML格式的几个数据表，转换并生成一个SQL转储作为输出，因此我可以将它直接传递给命令mysql，如在my_importer | mysql -options。当操作运行时，程序会将反馈输出到stderr，这样我就知道它的工作情况以及它到目前为止的输入情况。
答案 2 :(得分：0)
请记住，stderr并不是关于错误，而是关于诊断。任何诊断消息（包括调试模式通知和花哨的进度条）应该转到stderr，而所有的交互，无论是用户还是其他程序，都应该继续使用stdout。 stderr通常也连接到终端，而stdout可能是shell管道的一部分（因此不可见）。并且没有办法将stderr与stdout分开连接到下一个程序。
关于你的情况，关于错误号码的消息显然是交互的一部分，所以使用stdout。将活动对话移动到其他流是个坏主意。但是，如果用户/对等进程不打算读取并做出反应，而只是诊断/调试程序的人的信息，那么使用stderr。
答案 3 :(得分：0)
对于像你正在讨论的那样的互动节目，我认为它没有太大的区别。如果程序不能与标准输出和/或重定向的标准错误一起使用，那么您也可以简化并使用标准输出进行提示和诊断。
话虽如此，有很多场景需要重定向，甚至是某些用例正常工作的必要条件。如果有任何可以想象的方式可以以这种方式使用程序，那么确保标准输出仅包含实际生产输出非常重要，其他一切都会出现标准错误。