Размышления о блюзе — еще раз про exception handling

Написано уже немало про обработку исключений в C#, написано хорошо и местами подробно, но я попытаюсь внести свою скромную лепту в этот вопрос. Данная статья является просто некой попыткой лучше осмыслить и систематизировать в рамках одной, пусть даже очень условной концепции возможные подходы к проблеме. Хорошая практика обработки исключений, на мой взгляд, освещена довольно скудно и не создает целостной завершенной картины, когда, как и где работать с исключительными ситуациями в коде.

Разработчикам было бы неплохо с самого начала работы над проектом держать в уме некую «дорожную карту», которая охватывала бы все этапы разработки. «Смерть часть жизни» — сказала мама Форесту Гампу, нештатные ситуации — часть штатного функционирования системы, по этой причине учитывать возможность этих самых нештатных ситуаций, классифицировать их, начинать работать с ними уже на этапе проектирования, адекватно отражать в кодовой базе, и тем самым органично вплетать в структуру проекта, представляется мне таким же важным, как и реализация всего набора штатного функционала.

Как водиться, сначала попробуем определить термины. Заглянем в MSDN — «The C# language's exception handling features provide a way to deal with any unexpected or exceptional situations that arise while a program is running.» Очень интересное место в формулировке — unexpected or exceptional situations . На первый взгляд звучит как синонимы, но если вдуматься разница довольна ощутимая – исключительная ситуация во время выполнения определенного use case-а, и некое поведение системы, «системный use case», который сам по себе является исключительной ситуацией. Поясню подробнее, что имею ввиду. Стандартный workflow проектирования начинается с use case диаграмм, которые, грубо говоря, проецируют существительные из спецификации на actor-сущности, и глаголы на use case-сущности схемы. И, при тщательном подходе к формализации схемы, вхождение системы в каждое новое состояние (иллюстрируемое use case-ом), и выход из него должны происходить с соблюдением выполнения предусловий и постусловий. Для каждого состояния этот набор уникальный, общая черта – то, что выполнение всего этого набора гарантирует нахождение системы в корректном, консистентном состоянии. Следовательно, так как условия теоретически должны быть четко определены уже на этапе проектирования, любое рассогласование с ними порождает то, что в принципе и можно называть exceptional situations.

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

Теперь к главному – что же следует из всего этого с практической точки зрения. Исключения первого рода, информирующие о нарушении набора пред- и пост- условий должны обрабатываться как можно ближе к клиенту – код наиболее близкий к клиентской части знает про ожидаемое поведение больше всего. Именно на этот код должна быть возложена обязанность обработки таких исключений. Что касается исключений другого рода, unexpected situations, то работать с ними должен тот код, который реализует тот или иной функционал – код репозитория, если идет работа с БД, к примеру. И в этом случае обработчик напротив должен быть максимально близко к месту возникновения исключения.

В общем еще раз вместо заключения – эта маленькая заметка просто размышления на тему «негативных» сценариев поведения системы, и того, как с ними работать наилучшим образом.
  • –2
  • 4.7k
  • 6
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 6

    +4
    Не понятна суть статьи. Это похоже на беспорядочные философские рассуждения о предназначении исключений в среде NET. Слишком много воды для обучающего или «открывающего глаза серой массе» поста. Но направление мыслей в целом правильное.
      0
      Про «литье воды» замечание принимаю, надо работать над стилем изложения, но все же надеюсь здравые зерна во всех этих рассуждениях есть.
      0
      Эта техника уже относиться скорее к этапу кодирования,
      Образованные люди пишут практически без ошибок, но именно ошибка с мягким знаком в глаголах то и дело появляется в статьях. Заметил одну закономерность, которой хочу с вами поделиться (поэтому пишу не в личку):

      В глаголе с мягким знаком ударение на слоге с мягким знаком

      Так, из двух вариантов:
      1) отнОсится – ударение на букве О (второй слог)
      2) относИться – ударение на букве И (третий слог)
      произнося про себя вышеприведенное предложение, выбираем первый вариант.
        0
        Я определяю, ставить Ь или нет, гораздо проще — в русском языке окончание «ся» появилось относительно недавно, и представляет собой убранный пробел между неким глаголом и устаревшим словом «ся» (себя). Соответственно выглядит и окончание слова-глагола, как рассчитанное на спряжение со словом «себя».

        Пример: «техника относить себя к этапу» — ерунда какая-то, глагол «носить» не склонён никак, «техника относит (приближает) себя к этапу» — глагол склонён в настоящее время, суть предложения стала понятна.
        –1
        По иностранным терминам может быть, все наоборот:
        unexpected (неожиданные) situations – это неверные аргументы (ArgumentException), ведь метод ожидает expected range of values for the argument
        exceptional (исключительные) situations – это когда вызываемые в коде операции и методы порождают exceptions.

        Исключения первого рода, информирующие о нарушении набора пред- и пост- условий должны обрабатываться как можно ближе к клиенту – код наиболее близкий к клиентской части знает про ожидаемое поведение больше всего.
        Зачем коду, информирующему клиента, знать про ожидаемое поведение? Его дело – вывести сообщение об ошибке в виде диалогового окна, сделать запись в журнал, отправить уведомление по почте и т.д. А что именно произошло знает код, генерирующий исключение. Когда проверяются пред- и пост- условия- не удобнее ли там и сформировать текст сообщения об ошибке со всеми деталями что произошло?

        код, который реализует тот или иной функционал – код репозитория, если идет работа с БД, к примеру. И в этом случае обработчик напротив должен быть максимально близко к месту возникновения исключения.
        Не могли бы Вы подробнее описать, что будет делать этот обработчик?
          0
          В первом случае я имел ввиду поведение, контролируемое тем, что в нашем доморощенном переводе называется операционный уровень приложения, а в оригинале application layer. Сюда же с огромной натяжкой можно отнести контроллер из того же MVC-паттерна, к примеру. Это самый «высокоуровневый» код, который контролирует всякого рода мэнэджеры, хэлперы, контроллеры, и ту бизнесс-логику которую они отрабатывают, если речь идет про anemic domain model, или data driven design, если смотреть с точки зрения методологии проектирования, и контролирует фабрики, репозитории и агрегаты, если речь идет про domain driven design. То есть ближе всего use case соотносятся с методами именно application layer-а, и соответственно ответственность за некорректную отработку прецендентов было бы логично возложить именно на методы application layer-а. Это я имел ввиду, говоря про «код, наиболее близкий к клиенту» и «знающий больше всего про ожидаемое поведение».

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

        Only users with full accounts can post comments. Log in, please.