Очистить ведение журнала уровня отладки в Java?

Question

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

int i = 0;
logger.debug("Setting i to 0,"); //Just an example, would show something more complex
i++;

InputStream is = socket.getInputStream();
DataOutputStream dos = new DataOutputStream(socket.getOutputStream());

IOUtils.write(request, dos);
logger.debug("request written to output");

while (!is.read(buffer))
    logger.debug("Reading into buffer");

logger.debug("Data read completely from socket");

CustomObject.doStuff(buffer);
logger.debug("Stuff has been done to buffer");

Answer 1

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

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

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

Answer 2

Спросите себя, запускаю ли я это на другой машине / в стране / на планете, и что-то идет не так, и все, что у меня есть, - это только файл журнала. Какая информация мне нужна, чтобы узнать, что пошло не так? *

Использованиеотладочные журналы в цикле for или в цикле while.Например, если вы читаете 1000 записей из файла, выполните операцию для каждой записи.Вы можете записать перед циклом for, что «файл существует и доступен для чтения и будет читать 1000 записей», и состояние печати после завершения процесса.Если это, скажем, 1000000 записей, то вы могли бы печатать что-то каждые, скажем, 100 или 1000 итераций

В вашем коде, за исключением регистратора для установки i в 0, все остальное как-то имеет смысл для меня.Также не забывайте использовать log.isDebugEnabled (), если ваша строка в статистике логгера сложно вычислить ..

ex:

if(log.isDebugEnabled) {
   logger.debug("Here " + obj.aMethodCallThatTakes5MinsToEvaluateToString());
}

ОБНОВЛЕНИЕ 1: SLF4J решает только половину проблемы.

if(slfLog.isDebugEnabled) {
   slfLog.debug(obj.getObjectThatTakes5Mins());
}

Да, toString запрещен, но если вы регистрируете фактический объект, который является результатом некоторых вычислений, вам не мешают.

Answer 3

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

Если вы хотите, чтобы это было на более высоком уровне, возможно, добавление вашей регистрации с помощью AOP может помочь облегчить чтение, возможно, используйте прокси объект?

Но если у вас есть подробные инструкции по отладке, как в приведенном вами примере, ИМХО, вы могли бы получить больше, заменив регистраторы модульными тестами. Не пишите в журнале, что что-то случилось, проверьте, что это произошло.

Answer 4

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

То, что вы МОЖЕТЕ сделать, строго учитывает, что НУЖНО быть там. Вы в основном пишете для читателя файла журнала, который по определению не знает о том, как работает ваша программа, поэтому информация должна быть краткой и правильной. Лично я очень часто добавляю имя метода в оператор журнала.

Также обратите внимание, что slf4j позволяет вам использовать {} -синтаксис, который немного помогает

 log.debug("main() date={}, args={}", new java.util.Date(), args);

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