Какова лучшая стратегия обработки исключений в классах регистрации ошибок?

Question

Я пишу набор классов регистрации ошибок, который будет вести журнал в файл, журнал событий и т. Д. Какую обработку исключений следует выполнять в этих классах? Например, скажем, у меня есть метод LogError, который вызывается из обработчиков исключений и записывает в файл. Что считается лучшим, если возникнет ошибка? Очевидно, что я должен сделать эти методы максимально безопасными, но проблемы всегда могут возникнуть.

Answer 1

Почему вы не используете существующий механизм ведения журнала, такой как log4j / log4net / log4php / log4 *? Эти инструменты, вероятно, разбирают эти детали.

В качестве примечания: если вы запускаете свой код внутри контейнера (например, tomcat), даже если вы бросаете исключение в обработчик исключений, контейнер его перехватит и покажет. Как сказал Дуглас Лидер, вы можете перехватить все исключения внутри обработчика и отправить его в syserr.

Answer 2

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

Если запись в stderr не удалась, пришло время сдаться - либо проигнорируйте ее, чтобы полностью завершить приложение.

Answer 3

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

Служба аудита может быть реализована как конечный автомат, который может принимать и записывать сообщения на основе критериев, определенных в его конфигурации. Универсальный обработчик исключений также может использовать службу аудита для поддержки централизованного представления проблем, возникающих в корпоративной SOA, - для поддержки мониторинга на основе исключений. Любое условие «не должно происходить» в решении инструктируется для отправки сообщения об исключении в обработчик исключений .

Answer 4

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