Уровни отладки при написании приложения

Question

Я хотел бы знать, есть ли у вас, ребята, какие-либо предложения по уровням отладки при написании приложения.

Я думал о 4 уровнях:

0: без отладки
1: Все входы и выходы
2: уведомление «Я здесь» от важных функций с основными параметрами
3: Все переменные подробны

Answer 1

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

• LOG_SEVERE, серьезные ошибки, требующие выхода из программы (например, в приложении не хватило места на диске).
• LOG_ERROR, сообщения об ошибках, из которых невозможно восстановить, но программа может продолжать работать (например, в серверном приложении клиент отправил неверные данные, но другие клиенты могут продолжить работу).
• LOG_WARNING, устраняемая проблема, о которой вы должны быть уведомлены (например, неверное значение в файле конфигурации, поэтому вы вернулись к значению по умолчанию).
• LOG_INFO, информационные сообщения.
• LOG_ENTRY, запись журнала и выход для всех функций.
• LOG_PARM, запись в журнал и выход из всех функций с переданными параметрами и возвращенными значениями (включая глобальные эффекты, если таковые имеются).
• LOG_DEBUG, общие сообщения отладки, в основном полезная информация, которая может быть выведена в одну строку.
• LOG_HIDEBUG, гораздо более подробные сообщения отладки, такие как шестнадцатеричные дампы буферов.

Каждый уровень также регистрирует сообщения на «более низких» уровнях. Иногда возникал вопрос о том, должно ли отладочное сообщение быть LOG_DEBUG или LOG_HIDEBUG, но мы в основном основывали его на количестве строк, которые оно будет выдавать в файл журнала.

Answer 2

Я обычно использовал более четырех уровней, хотя они не обязательно имеют названия. Вы можете взглянуть на уровни, предоставляемые процессом демона 'syslog'.

0 - Emergency (emerg)
1 - Alerts (alert)
2 - Critical (crit)
3 - Errors (err)
4 - Warnings (warn)
5 - Notification (notice)
6 - Information (info)
7 - Debug (debug) 

(Пакет log4j добавляет уровень ниже 'debug', называемый 'Trace', но предоставляет только 'Fatal', где syslog и syslogd предоставлять экстренные, оповещения и критические замечания.) Они не имеют непосредственного отношения, но должны дать вам некоторую паузу для размышлений. Список, предоставленный Паксом, довольно разумный.

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

Вы можете найти источник, который я использую на GitHub, в моем SOQ (стек Переполнение Вопросы) хранилище в виде файлов debug.h, debug.c, mddebug.c в src / libsoq подкаталог.

Answer 3

у меня есть:

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

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

Answer 4

Что бы вы ни выбрали, вы захотите увидеть то, что находится на следующем уровне ...

Я не думаю, что есть общий ответ на этот вопрос, потому что это так зависит от того, что делает приложение. Подобно жирным страницам в руководстве Хейнса (читатели из Великобритании поймут, что я имею в виду), я склоняюсь к тому, что вы в конечном итоге ведете тяжелые лесозаготовки в тех областях, которые традиционно были проблемными, и почти ни одной в той области, которая будет Вы беспокоитесь следующий .

Answer 5

Это мой список:

• Тихий режим:

Приложение не генерирует ничего, связанного с отладкой. Ни при каких обстоятельствах приложение не будет отправлять что-либо на UART или отладочную консоль.

• Error-Mode:

Жесткие и неустранимые ошибки записываются в консоль.

• Внимание! Режим:

Включает дополнительную отладочную информацию, предназначенную для помощи другим программистам.

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

• Режим отладки (уровень 1-4)

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

Чем выше режим отладки, тем больше информации регистрируется.

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

Answer 6

0: без регистрации

1: регистрация исключений: регистрировать каждую выданную ошибку. Например, в c #: вход в блоки catch. Когда эти операции журнала запускаются, вы знаете, что у вас есть ошибка. Вы также можете войти в операторы switch, если есть случай, который никогда не должен ударить, и тому подобное.

2: регистрация операций: для операций регистрации, которые не находятся в блоках перехвата (обычные операции), должна быть установлена ​​высокая отладка. Таким образом, вы можете увидеть, какой метод начинает выполняться, а затем оказывается в блоке catch.

Кроме того, подумайте о переключателях регистрации, например, регистрации пакетов (true: протоколировать сетевые пакеты / сообщения, false: нет). Только не переусердствуйте с переключателями.

При обработке исключений каждое тело метода должно быть, по крайней мере, в блоке try-catch, по крайней мере, с общим уловом Exception в конце. Поместите запись в блок catch, добавьте дополнительную информацию помимо системного сообщения и трассировки стека, чтобы указать, что вызвало ошибку, а затем сгенерируйте ошибку. Прекратите выдавать ошибки только тогда, когда пользователь был уведомлен об ошибке или вы находитесь на верхнем уровне приложения, у которого нет активного пользовательского интерфейса. (Например, ведение журнала на стороне сервера.) В сообщении клиентскому приложению необходимо указать, что на стороне сервера произошла ошибка.

Answer 7

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

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

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

Спасибо за хорошие предложения!

Омри.

Answer 8

Что действительно важно при разных уровнях ведения журналов, так это то, что все разработчики используют одни и те же определения.

Я видел примеры того, как разработчики регистрировали ошибку из пакета tcp, когда не удалось доставить пакет, даже если он обрабатывается и вызывающая сторона выполняет повторную отправку.
Разработчик сказал: «Но в этом контексте это ошибка».

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

Точное количество уровней не так важно, как последовательное использование этих уровней в приложении.

Может быть очень полезно, если есть возможность изменять уровни во время выполнения и, если возможно, выбирать разные уровни для разных частей приложения.