Подтвердить что ты не робот

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

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

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

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

EDIT:

Это java, но может быть C/С++, basic и т.д.

4b9b3361

Ответ 1

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

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

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

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

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

Ответ 2

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

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

  • Различные объекты журнала. Различные классы/модули/etc могут регистрироваться на разных регистраторах, поэтому вы можете использовать различные конфигурации журналов для разных частей приложения.
  • Различные уровни журналов - поэтому вы можете настроить конфигурацию протоколирования только для ошибок журнала в производстве, для регистрации всех видов информации об отладке и трассировке в среде разработки и т.д.
  • Различные логические выходы - структура должна позволять вам настраивать, куда отправляется вывод журнала, без каких-либо изменений в кодовой базе. Некоторые примеры разных мест, в которые вы могли бы отправить вывод журнала, - это файлы, файлы, которые перекатываются на основе даты/размера, баз данных, электронной почты, удаленных приемников и т.д.
  • Структура журнала никогда не должна никогда не вызывать никаких исключений или ошибок из кода ведения журнала. Ваше приложение не должно не загружаться или не запускаться, поскольку структура журнала не может создать файл журнала или получить блокировку файла (если это не является критическим требованием, возможно, по юридическим причинам, для вашего приложения).

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

Ответ 3

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

Ответ 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 есть все, что вам нужно.

ИЗМЕНИТЬ

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

Ответ 5

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

  • Используйте фреймворк регистрации. Это позволит вам:

    • Легко изменить назначение сообщений журнала
    • Отфильтровать сообщения журнала на основе серьезности
    • Поддержка международных журнальных сообщений
  • Если вы используете java, то slf4j теперь предпочитают Jakarta commons logging в качестве фасада лесозаготовки.

  • Как указано, slf4j - это фасад, и вы должны затем выбрать базовую реализацию. Либо log4j, java.util.logging, либо "simple".

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

Ответ 6

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

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

Ответ 7

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

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

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

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

Ответ 8

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

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

Смотрите примеры SO или искать в Интернете.