Какая-либо причина не всегда зарегистрировать отслеживания стека?

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

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

Причина, по которой получение трассировки стека в виде строки запутано, состоит в том, что в JRE нет StringPrintWriter - я полагаю, что они думали, что они предоставляют множество ортогональных строительных блоков, которые вы затем комбинируете по мере необходимости. . Вам нужно собрать необходимый PrintWriter самостоятельно.

См. Также эти вопросы

Ведение журнала в Java и в целом: передовой опыт?

Лучшие методы ведения журнала Java из нескольких потоков?

Важные моменты, которые следует учитывать

1. Обработка конфиденциальных данных
2. Сжатие сообщений об исключениях и отправка их соответствующим специалистам по исправлению
3. Регистрация того, что требуется. Поскольку его регистрация дорогостоящая с точки зрения пространства и времени

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

Кстати, я согласен с sibidiba в отношении потенциального раскрытия информации о внутреннем устройстве вашего приложения, которое раскрывает полный стек: имена функций вместе с последовательностью вызовов стека могут многое рассказать образованному читателю. По этой причине некоторые продукты регистрируют в стеке только адрес символа и полагаются на то, что разработчики разрешат адрес в имя из внутренних PDB.

Но я считаю, что запись текста в файлы, содержащие 1 строку ошибки и 14 строк стека, очень затрудняет навигацию по журналам ошибок. Это также вызывает проблемы в приложениях с высокой степенью параллелизма, поскольку блокировка файла журнала сохраняется дольше (или, что еще хуже, файлы журнала чередуются). Я много раз сталкивался с этими проблемами, а также с другими проблемами, связанными с поддержкой и устранением неполадок при развертывании моих собственных приложений, что привело меня к созданию службы регистрации ошибок на bugcollect.com . При разработке политик сбора ошибок я решил собирать дамп стека каждый раз и использовать стеки как часть ключей корзины (чтобы сгруппировать ошибки, происходящие в одном стеке, в одну корзину).

Ограничения на ведение журналов часто проталкиваются, когда разработчики ведут слишком свободный журнал, а системные администраторы обнаруживают, что приложение, попав под производственную нагрузку, работает и заполняет HD огромными файлами журналов. Затем бывает трудно убедить их в том, что вы поняли ошибку и достаточно сократили ведение журнала (или настроили уровни журнала), но действительно нуждаетесь в оставшихся записях журнала.

Бонусные очки, если вы можете объяснить (почему, а не как) смысл необходимости прыгать через обручи в java, чтобы получить строковое представление трассировки стека!

Разве вы не должны просто регистрировать брошенную ошибку вместо того, чтобы перебирать все возможные способы печати трассировки стека? Например, так: log.error("Failed to deploy!", ex). При наличии отбрасываемого объекта Log4J выведет как сообщение об ошибке, полученное с помощью getMessage(), так и трассировку стека.

Я часто видел код, регистрирующий исключение, подобное этому:

LOG.error (ex);

Поскольку log4j принимает объект в качестве первого аргумента, он регистрирует строковое представление исключения , который часто является только именем класса. Обычно это просто недосмотр со стороны разработчика. Лучше регистрировать и ошибки следующим образом:

LOG.error ("foo Произошло", ex);

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