Регистрация хорошей практики

Question

Я использую sl4j / logback в качестве каркаса логирования.Я не уверен в правильном способе регистрации ошибок.А именно, предполагая, что e является Исключением, которое я хочу зарегистрировать, я всегда колеблюсь между:

1. logger.error("Something bad happened: {}\nError: {}", someInfo, e.getMessage());

   Я понимаю, что это не очень хорошая практика, потому что трассировка стекапотеряно - не здорово понимать, что произошло.

2. logger.error("Something bad happened: {}\nError: {}", someInfo, e.getMessage(), e);

   Использование обоих символов e.getMessage() и e кажется излишним, хотя я не знаю, так ли этовозможно, что e.getMessage() может содержать дополнительную информацию, которую не было бы видно, если бы я использовал:

3. logger.error("Something bad happened: {}", someInfo, e);

   , который я обычно использую - но яхочу убедиться, что я ничего не пропустил.

Answer 1

Я обычно использую номер два, хотя я НИКОГДА не разбиваю одну строку журнала на 2 строки (\ n), хотя при печати трассировки стека это не имеет большого значения (во всех других случаях это создает слишком большую визуальную энтропиюкогда ваши журналы становятся действительно огромными).

Почему я использую номер 2?

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

В случае, если мне нужно точно изучить, что произошло, я лучше посмотрю на трассировку стека.

Iс номером 3 тоже все в порядке, так как вы все равно получите необходимую информацию.НИКОГДА не используйте опцию 1.

Кстати, и просто особое мнение, говоря, что что-то плохое произошло в строке ОШИБКИ, немного избыточно;)

Answer 2

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

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

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

О, это для контролируемого доступа к файлу журнала, никогда не говорите, например, поместить трассировку стека в качестве ответа в asp.Хакеры мокрая мечта та.

Answer 3

Если вы посмотрите на исходный код Throwable (http://www.docjar.com/html/api/java/lang/Throwable.java.html)), вы обнаружите, что Throwable, когда его просят напечатать его трассировку стека, начинает с самой печати, что печатает его сообщение.

Я считаю маловероятным, что кто-то изменит это поведение, поэтому все ваши аргументы верны, а опция 3. в порядке