Что случилось с использованием System.err в Java?
Попробуйте:
intent.addFlags(Intent.FLAG_ACTIVITY_LAUNCHED_FROM_HISTORY)
7 ответов
Краткий ответ: считается плохой практикой использовать его для целей ведения журнала.
Это наблюдение, что в старые времена, когда не было широко доступных / принятых фреймворков ведения журнала, все использовал System.err для вывода сообщений об ошибках и трассировки стека на консоль. Этот подход может быть подходящим на этапе разработки и локального тестирования, но не подходит для производственной среды, поскольку вы можете потерять важные сообщения об ошибках. Из-за этого почти во всех инструментах статического анализа сегодня этот вид кода обнаруживается и помечается как плохая практика (или проблема с аналогичным названием).
Структуры ведения журнала, в свою очередь, обеспечивают структурированный и логичный способ регистрации ваших событий и сообщений об ошибках поскольку они могут хранить сообщение в различных постоянных местах (файл журнала, база данных журнала и т. д.).
Наиболее очевидным (и свободным от внешних зависимостей) решением хака является использование встроенной среды ведения журналов Java через класс java.util.logging.Logger при пересылке запись событий в консоль по умолчанию. Например:
final Logger log = Logger.getLogger(getClass().getName());
...
log.log(Level.ERROR, "Something went wrong", theException);
(или вы можете просто отключить этот параметр анализа)
дескриптор вашей ошибки:
Использование System.err может указывать на остаточную отладку или шаблонный код. Рассмотрите возможность использования полнофункциональный пакет ведения журнала, такой как Apache Commons, для обработки журнала ошибок.
Похоже, что вы используете System.err для ведения журнала, что неоптимально по нескольким причинам:
- невозможно включить ведение журнала во время выполнения без изменения поведение ведения журнала двоичного файла
- приложения не может контролироваться редактированием файла конфигурации
- вероятно многих других
System.err больше подходит для целей отладки, чем что-либо еще. Предпочтительна правильная обработка исключений и обработка ошибок более удобным для пользователя способом. Если пользователь должен увидеть ошибку, используйте вместо нее System.out.println.
Если вы хотите отслеживать эти ошибки с точки зрения разработчика, вам следует использовать регистратор.
Вещи, записанные в System.err, обычно теряются во время выполнения, поэтому считается лучшей практикой использовать структуру ведения журнала, которая является более гибкой в отношении того, где выводить сообщение, чтобы его можно было сохранить в виде файла и проанализировать.
System.err и System.out для неконсольных приложений встречаются только когда-либо разработчик запускает код в своей среде IDE, и полезная информация может быть потеряна, если элемент запускается в производственной среде.
Хотя я согласен с приведенными выше пунктами об использовании среды ведения журналов, я все же склонен использовать вывод System.err в одном месте: внутри обработчиков выключения. Это связано с тем, что я обнаружил, что при использовании фреймворка java.util.logging операторы журнала не всегда отображаются, если они встречаются в обработчиках завершения работы. Это связано с тем, что библиотека регистрации предположительно содержит свой собственный обработчик выключения для очистки файлов журнала и других ресурсов, и поскольку вы не можете полагаться на порядок, в котором выполняются обработчики выключения, вы не можете полагаться на java.util.logging операторы работают должным образом.
Ознакомьтесь с этой ссылкой (раздел «Комментарии») для получения дополнительной информации по этому поводу.
http://weblogs.java.net/blog/dwalend/archive/2004/05/ shutdown_hooks_2.
System.err.println и System.out.println не должны использоваться в качестве интерфейса ведения журнала. STD-Output и STD-Error (они записываются в System.out и .err) предназначены для сообщений от инструментов командной строки.
System.err выводит на консоль. Это может быть подходящим для студента, проверяющего свое домашнее задание, но не подходит для приложения, в котором эти сообщения не будут видны (консоль хранит только такое количество строк).
Лучшим подходом было бы создать исключение, содержащее сообщение это обычно отправляется на консоль. Альтернативой этому может быть использование стороннего программного обеспечения для ведения журнала, которое сохранит эти сообщения в файле, который можно хранить вечно.