Когда использовать sys.stdout вместо sys.stderr?

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 --- просто фатальные ошибки или любое сообщение об ошибке?

Оба примера являются сообщениями об ошибках, но один из них - это просто «Программа не работает». У меня возникли проблемы с выбором того, куда следует отправлять такое сообщение.

Answer 1

Неустранимая ошибка, безусловно, должна идти в stderr. Нормальный выход должен идти в стандартный вывод.

Существует серая область для информационных сообщений, но в целом они не должны идти на stdout, если они делают вывод недоступным. Люди часто направляют stdout в файл и stderr либо в терминал, либо в файл журнала.

Вам нужно решить, какое деление имеет наибольший смысл.

Answer 2

Том Karzes уже дал вам правильный ответ, но сформулировать более крайнюю позицию ...

Я считаю, что это помогает думать о stdout и stderr как «стандартный вывод» и «стандартной not- вывод". Вы сказали, что думаете, что сообщение «должно идти до stdout, потому что это не ошибка», но это наоборот: stdout - это поток с высоким барьером для входа, а не stderr.

сообщение должно пойти stderr (или лог-файл, или что-нибудь, но stdout), если это не доказуемо часть требуемой продукции --- конечный продукт, что пользователь действительно хочет . Если вы не можете оправдать его включение предложением, которое начинается, «Пользователь просил ...», не загрязняет stdout с ним. (Следующий процесс в трубопроводе будет вам благодарен.)

Коэффициенты: ваши пользователи не запускали вашу программу, потому что они хотели посмотреть закрутую дубинку или прочитать дюжину сообщений «Попытка воссоздать ...» , или даже узнать, какие вилки потерпели неудачу, поэтому они должны не быть на stdout.

И, наконец, некоторые сообщения не должны идти либо выходного потока.stderr, по-видимому, читается пользователем, поэтому постарайтесь ограничить его вывод теми вещами, которые пользователь заботится о прямо сейчас. Не освобождайте его от сообщений о ситуации, если пользователь специально не запросил их, включив многословие (обычно --verbose или --debug). По крайней мере, разрешите пользователю отключать ошибки, используя опцию --quiet или --silent. Большинство «информационных» сообщений следует отправлять в файл журнала вместо консоли.