Каковы лучшие практики для регистрации ошибки?

Question

Много раз я видел протоколирование таких ошибок:

System.out.println("Method aMethod with parameters a:"+a+" b: "+b);
print("Error in line 88");

так .. Каковы лучшие методы для регистрации ошибки?

EDIT:

Это Java, но может быть C / C ++, базовый и т. Д.

Answer 1

Вход непосредственно в консоль ужасен и, откровенно говоря, признак неопытного разработчика. Единственная причина для такого рода действий состоит в том, что 1) он или она не знают о других подходах и / или 2) разработчик не задумывался над тем, что произойдет, когда его / ее код будет развернут на рабочем сайте, и как приложение будет поддерживаться на этом этапе. Работа с приложением, которое регистрирует 1 ГБ / день или более полностью ненужных журналов отладки, сводит с ума.

Общепринятая лучшая практика заключается в использовании каркаса ведения журналов, который имеет следующие понятия:

1. Разные объекты журнала - разные классы / модули / и т. Д. Могут регистрироваться в разных регистраторах, поэтому вы можете применить разные конфигурации журнала к разным частям приложения.
2. Различные уровни журналов - так что вы можете настроить конфигурацию журналов, чтобы регистрировать только ошибки в производственной среде, регистрировать всевозможные данные отладки и трассировки в среде разработки и т. Д.
3. Различные выходные данные журнала - инфраструктура должна позволять вам настраивать , где отправляется выходные данные журнала, не требуя каких-либо изменений в кодовой базе. Примерами различных мест, в которые вы, возможно, захотите отправить выходные данные журнала, являются файлы, файлы, которые перемещаются по дате / размеру, базы данных, электронная почта, приемники удаленного взаимодействия и т. Д.
4. Каркас журнала никогда не должен никогда никогда выбрасывать исключения или ошибки из кода регистрации. Приложение не должно загружаться или не запускаться, потому что каркас журнала не может создать свой файл журнала или получить блокировку файла (если это не является критическим требованием, возможно, по юридическим причинам, для вашего приложения).

Возможная структура журнала, который вы будете использовать, будет зависеть от вашей платформы. Некоторые общие опции:

• Java:
  • Apache Commons Logging
  • log4j
  • Logback
  • Встроенный java.util.logging
• .NET:
  • log4net
• C ++:
  • log4cxx

Answer 2

Apache Commons Logging не предназначен для приложений общего ведения журналов. Он предназначен для использования библиотеками или API, которые не хотят навязывать реализацию ведения журнала пользователю API.

Есть также проблемы с загрузкой классов в Commons Logging.

Выберите один из [многих] API журналирования, наиболее широко используемым, вероятно, является log4j или Java Logging API .

Если вам нужна независимость от реализации, вы можете рассмотреть SLF4J , от первоначального автора log4j.

Выбрав реализацию, затем используйте уровни / серьезность ведения журнала в этой реализации последовательно , чтобы упростить поиск / фильтрацию журналов.

Answer 3

Некоторые рекомендуемые лучшие практики

• Использование каркаса ведения журнала. Это позволит вам:

  • Легко измените место назначения ваших сообщений журнала
  • Фильтровать сообщения журнала по степени серьезности
  • Поддержка интернационализированных сообщений журнала

• Если вы используете java, тогда slf4j теперь предпочтительнее, чем Джакартское сообщество, регистрирующее как фасад регистрации.

• Как указано, slf4j является фасадом, и вам нужно выбрать базовую реализацию. Либо log4j, java.util.logging, либо «простой».

• Следуйте рекомендациям вашей платформы, чтобы обеспечить дорогостоящие операции регистрации не выполняются без необходимости

Answer 4

Рекомендуется использовать инфраструктуру java.util.logging

Затем вы можете регистрировать сообщения в любом из этих форматов

log.warning("..");
log.fine("..");
log.finer("..");
log.finest("..");

Или

log.log(Level.WARNING, "blah blah blah", e);

Затем вы можете использовать logging.properties (пример ниже), чтобы переключаться между уровнями ведения журнала, и делать все виды умных вещей, таких как запись в файлы, с вращением и т. Д.

handlers = java.util.logging.ConsoleHandler

.level = WARNING

java.util.logging.ConsoleHandler.level = ALL

com.example.blah = FINE
com.example.testcomponents = FINEST

По моему мнению, следует избегать таких фреймворков, как log4j и другие, в Java уже есть все, что вам нужно.

EDIT

Это может применяться в качестве общей практики для любого языка программирования. Возможность контролировать все уровни ведения журнала из одного файла свойств часто очень важна в корпоративных приложениях.

Answer 5

Самый простой способ регистрировать ошибки в согласованном формате - это использовать каркас журналирования, такой как Log4j (при условии, что вы используете Java). Полезно включить раздел журналирования в стандарты кода, чтобы все разработчики знали, что нужно регистрировать. Приятной особенностью большинства каркасов ведения журналов является то, что они имеют разные уровни ведения журнала, поэтому вы можете контролировать, насколько многословно ведение журнала между разработкой, тестированием и производством.

Answer 6

Помимо технических соображений из других ответов, рекомендуется записать значимое сообщение и, возможно, некоторые шаги, чтобы избежать ошибки в будущем. В зависимости от ошибок, конечно.

Вы можете получить больше от ошибки ввода-вывода, если в сообщении указано что-то вроде «Не удалось прочитать из файла X, у вас нет соответствующего разрешения.»

См. Больше примеров по SO или поиску в сети .

Answer 7

API общего ведения журнала Apache, как упомянуто выше, является отличным ресурсом. Возвращаясь к java, также имеется стандартный поток вывода ошибок (System.err).

Непосредственно из Java API:

Этот поток уже открыт и готов принять выходные данные.

Обычно этот поток соответствует вывод на дисплей или другой вывод назначение, указанное хостом среда или пользователь. Условно, этот выходной поток используется для отображения сообщения об ошибках или другая информация это должно прийти к немедленному внимание пользователя, даже если основной выходной поток, значение переменная, была перенаправлена в файл или другое место назначения, которое обычно не контролируется непрерывно.

Answer 8

На самом деле не существует лучшей практики для регистрации ошибок. По сути, он просто должен следовать последовательному шаблону (в программном обеспечении / компании / и т. Д.), Который предоставляет достаточно информации для отслеживания проблемы. Например, вы можете отслеживать время, метод, параметры, вызывающий метод и т. Д.

Пока вы просто не печатаете "Ошибка в"