Comments 6
Не понятна суть статьи. Это похоже на беспорядочные философские рассуждения о предназначении исключений в среде NET. Слишком много воды для обучающего или «открывающего глаза серой массе» поста. Но направление мыслей в целом правильное.
Эта техника уже относиться скорее к этапу кодирования,Образованные люди пишут практически без ошибок, но именно ошибка с мягким знаком в глаголах то и дело появляется в статьях. Заметил одну закономерность, которой хочу с вами поделиться (поэтому пишу не в личку):
В глаголе с мягким знаком ударение на слоге с мягким знаком
Так, из двух вариантов:
1) отнОсится – ударение на букве О (второй слог)
2) относИться – ударение на букве И (третий слог)
произнося про себя вышеприведенное предложение, выбираем первый вариант.
Я определяю, ставить Ь или нет, гораздо проще — в русском языке окончание «ся» появилось относительно недавно, и представляет собой убранный пробел между неким глаголом и устаревшим словом «ся» (себя). Соответственно выглядит и окончание слова-глагола, как рассчитанное на спряжение со словом «себя».
Пример: «техника относить себя к этапу» — ерунда какая-то, глагол «носить» не склонён никак, «техника относит (приближает) себя к этапу» — глагол склонён в настоящее время, суть предложения стала понятна.
Пример: «техника относить себя к этапу» — ерунда какая-то, глагол «носить» не склонён никак, «техника относит (приближает) себя к этапу» — глагол склонён в настоящее время, суть предложения стала понятна.
По иностранным терминам может быть, все наоборот:
unexpected (неожиданные) situations – это неверные аргументы (ArgumentException), ведь метод ожидает expected range of values for the argument
exceptional (исключительные) situations – это когда вызываемые в коде операции и методы порождают exceptions.
unexpected (неожиданные) situations – это неверные аргументы (ArgumentException), ведь метод ожидает expected range of values for the argument
exceptional (исключительные) situations – это когда вызываемые в коде операции и методы порождают exceptions.
Исключения первого рода, информирующие о нарушении набора пред- и пост- условий должны обрабатываться как можно ближе к клиенту – код наиболее близкий к клиентской части знает про ожидаемое поведение больше всего.Зачем коду, информирующему клиента, знать про ожидаемое поведение? Его дело – вывести сообщение об ошибке в виде диалогового окна, сделать запись в журнал, отправить уведомление по почте и т.д. А что именно произошло знает код, генерирующий исключение. Когда проверяются пред- и пост- условия- не удобнее ли там и сформировать текст сообщения об ошибке со всеми деталями что произошло?
код, который реализует тот или иной функционал – код репозитория, если идет работа с БД, к примеру. И в этом случае обработчик напротив должен быть максимально близко к месту возникновения исключения.Не могли бы Вы подробнее описать, что будет делать этот обработчик?
В первом случае я имел ввиду поведение, контролируемое тем, что в нашем доморощенном переводе называется операционный уровень приложения, а в оригинале application layer. Сюда же с огромной натяжкой можно отнести контроллер из того же MVC-паттерна, к примеру. Это самый «высокоуровневый» код, который контролирует всякого рода мэнэджеры, хэлперы, контроллеры, и ту бизнесс-логику которую они отрабатывают, если речь идет про anemic domain model, или data driven design, если смотреть с точки зрения методологии проектирования, и контролирует фабрики, репозитории и агрегаты, если речь идет про domain driven design. То есть ближе всего use case соотносятся с методами именно application layer-а, и соответственно ответственность за некорректную отработку прецендентов было бы логично возложить именно на методы application layer-а. Это я имел ввиду, говоря про «код, наиболее близкий к клиенту» и «знающий больше всего про ожидаемое поведение».
Далее по второму случаю, и тому, что будет делать обработчик — здесь банальное поддержание согласованности данных, когда это представляется возможным. Когда нет — падение с фиксацией описания ошибки для скорейшей локализации и расследования причин, ничего нового тут не сказал.
habrahabr.ru/post/126374/ исходя из этой градации, думаю то, что я имею ввиду, относиться к строгой гарантии.
Далее по второму случаю, и тому, что будет делать обработчик — здесь банальное поддержание согласованности данных, когда это представляется возможным. Когда нет — падение с фиксацией описания ошибки для скорейшей локализации и расследования причин, ничего нового тут не сказал.
habrahabr.ru/post/126374/ исходя из этой градации, думаю то, что я имею ввиду, относиться к строгой гарантии.
Sign up to leave a comment.
Размышления о блюзе — еще раз про exception handling