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

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

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

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

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

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

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

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