Следует ли отправлять предупреждающие сообщения приложения с графическим интерфейсом в std :: cerr? - PullRequest
Новая
       14

Следует ли отправлять предупреждающие сообщения приложения с графическим интерфейсом в std :: cerr?

3 голосов
/ 05 октября 2010

Должно ли предупреждение приложения графического интерфейса Unix отправляться в std :: cerr или std :: cout?

Это предполагает, что графический интерфейс обычно отображает предупреждения и ошибки в окне консоли, а также отправляет их в файл журнала.,Но в случае, если консоль отсутствует и, следовательно, не может быть использована, следует ли использовать std :: cerr, std :: cout или std :: clog для таких сообщений?

Я думаю, std :: cerrгде они принадлежат.

Ответы [ 5 ]

6 голосов
/ 05 октября 2010

Я предпочитаю cerr. Если пользователь направляет вывод или отправляет его в файл, он может отказаться от cerr с помощью 

tool 2>/dev/null >output

но все в одном потоке оставляет их SOL.

Также cerr небуферизован, поэтому сообщения об ошибках гарантированно будут появляться независимо от того, как сильно вы рухнули и сгорели. И предупреждения должны передаваться вместе с ошибками, если пользователь заменил /dev/null выше чем-то другим ... Я не уверен, является ли это отдельным аргументом или нет.

4 голосов
/ 05 октября 2010

Если ваша программа предназначена для вывода правильно отформатированного файла, который может быть передан другой программе или будет проанализирован, лучше перенаправить предупреждения на std::cerr.

1 голос
/ 05 октября 2010

В Windows ни std :: cerr, ни std :: cout никуда не направляются из программы с графическим интерфейсом, они просто идут в этот большой сегмент в небе. Полагаю, вы говорите о * nix-системах.

1 голос
/ 05 октября 2010

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

То же базовое правило применимо к большинству других программ: если рассматриваемое «сообщение» является частью «стандартного» вывода этой программы, и пользователь обычно ожидает, что оно будет включено, когда / если они перенаправят вывод, тогда это должно быть записано в стандартный вывод. Стандартная ошибка предназначена для сообщений, которые пользователь обычно хочет / должен видеть, даже если они имеют стандартный вывод, перенаправленный в файл - в первую очередь те, в которых говорится, что программа не может быть запущена, поэтому нет вывода или если он может быть неполным или недействительным.

0 голосов
/ 23 марта 2019

Это может помочь ОП. Вот что мы делаем:

  1. перенаправить stderr в локальный файл журнала (один файл журнала на один процесс)
  2. используйте наш собственный syslog() клиент (с фронтом C ++) (и локальный сервер Syslog Watcher )
  3. когда мы используем openlog() с LOG_PERROR каждое сообщение syslog также отправляется в локальный файл журнала
  4. мы вообще не используем iostreams
  5. мы используем консоль только для нашей крошечной тестовой среды

Правильно, это не * nix. На нашу защиту также не WIN32. Мы не делаем приложения пользовательского интерфейса.

...