Написано уже немало про обработку исключений в 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, то работать с ними должен тот код, который реализует тот или иной функционал – код репозитория, если идет работа с БД, к примеру. И в этом случае обработчик напротив должен быть максимально близко к месту возникновения исключения.
В общем еще раз вместо заключения – эта маленькая заметка просто размышления на тему «негативных» сценариев поведения системы, и того, как с ними работать наилучшим образом.
Автор: brewerof
