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

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

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

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

• Бесшумный режим:

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

• Режим ошибки:

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

• Режим предупреждения:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Омри.

У меня есть:

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

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

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

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

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

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

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

Обычно я использовал более четырех уровней, хотя у них не обязательно есть имена. Вы можете посмотреть уровни, предоставляемые процессом демона 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 добавляет уровень ниже «отладки» под названием «Trace», но предоставляет только «Fatal», где syslog и syslogd обеспечивают Emergency, Alerts и Critical.) Они не имеют прямого отношения, но должны дать вам некоторую паузу для размышлений. Список, предоставленный Pax, довольно разумный.

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

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