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

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

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

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

Я имею:

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

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

Независимо от того, что Вы выбираете, будет что-то, что Вы хотели видеть, который является только на следующий уровень...

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

Я обычно использовал больше, чем всего четыре уровня, хотя у них не обязательно есть имена. Вы могли бы посмотреть на уровни, обеспеченные' 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 добавляет уровень ниже 'отладки' под названием 'Трассировка', но обеспечивает просто 'Фатальный', где syslog и syslogd обеспечивают Чрезвычайную ситуацию, Предупреждения и Очень важный.) Они не непосредственно релевантны, но должны дать Вам некоторую паузу для мысли. Список, предоставленный Миром, довольно разумен.

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

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

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

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

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

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

Omri.

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

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

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

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

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

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

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

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

• Ошибочный Режим:

Трудные и неисправимые ошибки зарегистрированы к консоли.

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

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

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

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

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

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

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

0: никакой вход

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

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

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

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