Когда начинать писать обработку исключений, ведение журнала

Когда вы начнете писать код обработки исключений? Когда вы начнете писать заявления о ведении журнала.

В целях проработки этого вопроса, давайте предположим, что мы на платформе .NET с журналированием log4net, но не стесняйтесь отвечать в общем виде.

Решение: проект Windows Forms. Проекты: пользовательский интерфейс, BusinessRules, DataHandlers

Итак, вы собираетесь писать свои DataHandlers, которые сначала выполняют ваши манипуляции с данными, такие как создание, чтение, обновление, удаление.

Затем следуйте этим правилам.

А потом ваш пользовательский интерфейс или любая другая перестановка из вышеперечисленного.

Протестируйте свое приложение на функциональность.

А затем начните писать код обработки исключений и, наконец, код регистрации?

Когда подходящее время начать писать код обработки исключений?

PS: в книге « Чистый код» говорится: « Сначала напишите свой блок try-catch-finally . Это побудило меня задать этот вопрос.

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

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

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

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

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

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

В противном случае вы обнаружите, что у вас есть задачи для версии 2.0, такие как «Улучшение обработки ошибок» и «Создать систему ведения журнала». Они будут сокращены в пользу новых функций, и поскольку у вас есть «слишком много дел», исправьте все эти ошибки в тех случаях ошибок, о которых вы не задумывались. (Который занимает вечность, потому что у вас нет системы регистрации.

Зависит от того, что вы делаете

для исключений:

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

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

В любом случае, если у вас нет ничего полезного в связи с ошибкой, подумайте над тем, чтобы она всплыла (без обработчика).

для ведения журнала:

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

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

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

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

Напишите это, когда вам это нужно, но дизайн для их включения с самого начала.

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