2013-07-17 02:30:00
... ответственность за любой решение.
Ваш доставщик пицы ... делать.
Потому что решение зависит от вещей ...
+ развернуть текстсохранённая копия
Продолжаю цикл переводов понравившейся мне статьи автора James Dingle про исключения.
Первый пост посвященный этой статье находится здесь.
1. Выбрасывайте исключение когда вы не знаете, что делать дальше
Думайте о вашем коде как о компании.
Индивидуальные функции и методы это индивидуальные сотрудники, классы это менеджеры.
Библиотеки это главные офицеры, и точка входа в Main() это ваш CEO.
Во всех компаниях, сотрудники иногда встречаются с ситуациями к которым они не готовы.
Или которые слишком велики для них, чтобы они взяли ответственность за любой решение.
Ваш доставщик пицы не может починить свой мотоцикл, если тот не хочет заводиться.
Что он сделает в таком случае ? Он позвонит своему менеджеру
Сделайте тоже самое со своим кодом.
Когда вы столкнулись с ошибкой. Но при этом вы не можете решить что делать.
Потому что решение зависит от вещей за пределами контекста метода или функции, которые выбрасывают исключение.
Не стыдитесь этого.
Ваш метод должен сделать то, что он должен сделть или провалиться.
Нет никакой проблемы в том чтобы провалиться в случае, если нет способа решить проблему соответствующим образом.
Пример: вы написали функцию GetImageSize(string fileName), которая рассчитывает размер файла с изображением по имени файла находящегося на диске.
При этом, возможно, вы используете эту функцию во множестве ситуаций в вашем приложении.
Если эта функция накроется или заглючит (потому что например указанный файл не картинка), то не пытайтесь ничего предпринять.
Вы пропустили контекст (находитесь вне его).
Внутри этой функции вы не имеете ключевой информации кто попросил сделать это и для чего.
Так что вызвать NotAnImageException или BadFormatException это все что вы можете сделать.
Продолжаю цикл переводов понравившейся мне статьи автора James Dingle про исключения.
Предыдущий кусок находится здесь.
Почему я должен писать эффективные журналы исключений ?
Написание эффективной системы перехвата и логирования исключений это не самая сексуальная (приятная, красивая) часть вашего приложения или службы.
Хорошее или плохое логирование не изменит то, что делает ваше приложение. Так зачем заниматься и тем и другим ?
Однако, это одно из наиболее важных свойств вашего продукта в случае, если кто-нибудь захочет исследовать проблемы возникшие в нем.
Я придерживаюсь стандартов кодирования ориентированных на качество. Мои приложения полностью протестированы.
Почему я нуждаюсь в логировании и обработке исключений ?
Приложения никогда не бывают автономны, они всегда живут внутри окружения.
Когда окружение не ведет себя так, как ожидает ваше приложение. Тогда ошибки, возможно, произойдут.
Ваше приложение не так часто диагностирует себя в другом или неправильном окружении.
Но оно может сказать вам о том, что оно ожидало, и чего оно не получило.
Если ваше приложение исполняется в более сложном окружении, чем кокон в котором оно было разработано.
Или кто то овладел вашим кодом и добавил в него новые особенности (возможности).
То, возможно, он будет нуждаться в анализе того, что же он сделал не так.
Иногда бывает очень сложно подключить отладчик на продакшене и приходится выполнять в уме код.
Иногда идентификация набора действий, который привел к ошибке, это вызов само по себе.
Например, поиск условий гонки между несколькими задачами, которые привели к замку смерти.
И да, возможно, вы захотите исследовать ваши собственные ошибки тоже.
Так что, давайте начинать. В качества предварительного чтения советую
это.
Начинаю цикл переводов понравившейся мне статьи автора James Dingle про исключения.
Оригинал находится здесь: Efficient logging and exception handling in Windows and Web services : Part 1 – Raising exceptions, writing dumps .
Есть много статей обсуждающих лучшие практики работы с исключениями. И они почти все рекомендуются к прочтению.
Они обычно обсуждают паттерны кода. Но в этой статье я буду обсуждать паттерны дизайна (проектирования) приложений.
Чтение логов - наиболее часто оно представляет собой путешествие в ад.
Разве вы не проводили часы и дни расследований случаев исключений. Только потому, что вы имели нерелевантную или не полную информацию в ваших лог файлах ?
И вы не были в отчаянии, от того как бедно было сделано логирований в этом инструменте или сервисе ?
Случалось ли так что вы подключали сложный набор отладчиков и настройщиков с кучей скрытых настроек и звуковым оповещением обнаружения исключений ?
И все это только для того, чтобы обнаружить скрытые ошибки, которые ваше приложение не хотело вам показывать. Скрытые как древнее сокровище в гробнице
программных ошибок.
Если все это случалось с вами, то вы, должно быть, были сильно удивлены и дизориентированны загадочностью залогированной информации.
Пытаясь найти ваш ключ, который помогает решить ранее неразрешимую загадку, в направлении этих иероглифов невыразимых событий.
Хихикая от своего невежества о том, как звучит то, что там написано, на другом языке. Примечание: здесь видимо имеется ввиду произнесение
написанного иероглифами.
Мы тоже сталкивались с этим. И теперь мы горды тем, что мы написали такую статью вам в помощь.
