Я хотел бы знать, есть ли у вас какие-либо предложения относительно уровней отладки при написании приложения.
Я думал о 4 уровнях:
0: нет отладки
1: Все входы и выходы
2: "Я здесь" уведомление от важных функций с основными параметрами
3: Все переменные verbose
Вот что мы сделали в одном проекте, над которым я работал. Это не библия уровней каротажа, а одна возможность. Вход в систему должен быть установлен в вашей ситуации.
Каждый уровень также регистрирует сообщения на "нижних" уровнях. Иногда возникал вопрос о том, должно ли сообщение отладки быть LOG_DEBUG или LOG_HIDEBUG, но мы в основном основывали его на количестве строк, которые он выталкивал бы в файл журнала.
У меня есть:
Нормализуются блокировки самых низких двух уровней. Но другие показаны. И если вы хотите заблокировать уровень Fatal, все в порядке со мной, но не ожидайте, что после этого я очищу беспорядок (к сожалению, мне еще нужно...).
Я обычно использовал более четырех уровней, хотя они не обязательно имеют имена. Вы можете посмотреть уровни, предоставленные процессом демона 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)
Они не имеют прямого отношения к делу, но должны дать вам некоторую паузу для размышлений. Список, предоставленный Pax, довольно разумный.
Одной вещью, которую я часто нашел полезной, является сегментация отладки - разные уровни отладки, устанавливаемые для разных компонентов системы. Например, в зависимости от того, где проблема, мне может потребоваться большая отладка в разделе ввода и разделе управления макросами, не требуя отладки в основном коде обработки. Один уровень отладки во всей программе значительно лучше, чем ничего, но для сложных программ дифференциация неоценима.
Да, у меня есть исходный код, который я использую, - свяжитесь со мной (первая точка в gmail dot com), если вы хотите получить копию.
Независимо от того, что вы выберете, вы увидите что-то, что вы хотите увидеть, которое находится на следующем уровне...
Я не думаю, что есть общий ответ на этот вопрос, потому что он так зависит от того, что делает приложение. Подобно маслянистым страницам в руководстве Haynes (читатели из Великобритании узнают, что я имею в виду), я, как правило, обнаруживаю, что в итоге вы столкнулись с тяжелыми лесозаготовками в районах, которые традиционно были неприятными, и почти никого в районе, который будет вызывать вы беспокоитесь о будущем.
Это мой список:
Приложение не испускает связанных с отладки. Ни при каких обстоятельствах приложение ничего не выведет на UART или отладочную консоль.
В консоль записываются жесткие и невосстанавливаемые ошибки.
Включает дополнительную отладочную информацию, предназначенную для других программистов.
Этот режим не предназначен для обнаружения ошибок, но для предоставления информации другим программистам, которые используют мои приложения/библиотеку. В режиме предупреждения я в основном проверяю входные параметры и пытаюсь определить, пытается ли кто-то сделать что-то глупое. Подобно грубой силе решения или передавая только тот тип данных, который наиболее медленный.
В режиме отладки я начинаю регистрировать все, отсортированные по частоте появления. Уровень 1 не очень многословный. Основные вещи, которые моя программа/приложение выполнили, регистрируются. Не намного больше. Этот режим предназначен для получения приблизительного представления о том, что делает клиент.
Чем выше режим отладки, тем больше информации регистрируется.
Мой самый высокий уровень отладки зарезервирован для всех межпроцессных и межпроцессорных коммуникаций. Все обращения к семафорам, e-mutexes будут регистрироваться с максимальной детализацией.
Что действительно важно при разных уровнях ведения журнала, так это то, что все разработчики используют одни и те же определения.
Я видел примеры того, как разработчики регистрируют ошибку из пакета tcp, когда не удается доставить пакет, даже если он обрабатывается, и повторный вызов выполняется вызывающим. Разработчик, о котором идет речь, сказал: "Но в этом контексте это ошибка".
Вам нужно определить такие вещи, как:
Ошибка означает, что приложение потерпело неудачу и должно быть перезапущено.
Предупреждение может означать, что одна функция приложения не удалась, но приложение может восстановить и продолжить
и так далее...
Точное количество уровней не так важно, как последовательное использование этих уровней во всем приложении.
Это может быть очень полезно, если можно изменить уровни во время выполнения и, если возможно, выбрать разные уровни для разных частей приложения.
Я отступал, чтобы отделить журналы отладки от журналов аудита и журналов исключений. поэтому журналы, которые являются информативными, например, функция SendMessage, которая завершилась успешно или нет, будет журналами аудита, но журналы любого отказа приложения для отправки этого сообщения, вызвавшего исключение, будут журналами исключений.
Журналы отладки предназначены для использования только для целей отладки. уровни для меня, чтобы выбрать, насколько серьезной будет отладка.
Я думаю, что для разработчиков, которые работают в группе, важно установить эти правила до того, как они начнут код... поэтому запись будет состоять.
Спасибо за хорошие предложения!
Омри.
0: нет регистрации
1: журнал регистрации исключений: регистрируйте каждую порожденную ошибку. Например, в С#: регистрация в блоках catch. Когда эти операции с журналом запускаются, вы знаете, что у вас есть ошибка. Вы также можете регистрировать операторы switch, если есть случай, который никогда не должен быть удачным и тому подобное.
2: ведение журнала операций: операции регистрации, которые не находятся в блоках catch (обычные операции), должны быть настроены на высокую отладку. Таким образом, вы можете увидеть, какой метод запускается, а затем заканчивается в блоке catch.
Кроме того, подумайте о параметрах протоколирования, например о регистрации пакетов (true: log network packets/messages, false: do not). Просто не переусердствуйте с помощью переключателей.
При обработке исключений каждый орган метода должен быть, по крайней мере, в блоке try-catch, по крайней мере, с общим выводом Exception в конце. Поместите регистрацию в блок catch, добавьте дополнительную информацию, помимо системного сообщения и трассировку стека, чтобы указать, что вызвало ошибку, а затем выбросите ошибку. Остановите отправку ошибок дальше только тогда, когда пользователь был уведомлен об ошибке, или вы находитесь на верхнем уровне приложения, у которого нет активного пользовательского интерфейса. (Например, ведение журнала на стороне сервера.) Затем вам нужно указать в сообщении клиентскому приложению, что ошибка произошла на стороне сервера.