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

[ATauenis]

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

[brewerof]

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

[movsb]

Эта техника уже относиться скорее к этапу кодирования,

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

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

Так, из двух вариантов:
1) отнОсится – ударение на букве О (второй слог)
2) относИться – ударение на букве И (третий слог)
произнося про себя вышеприведенное предложение, выбираем первый вариант.

[ATauenis]

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

Пример: «техника относить себя к этапу» — ерунда какая-то, глагол «носить» не склонён никак, «техника относит (приближает) себя к этапу» — глагол склонён в настоящее время, суть предложения стала понятна.

[movsb]

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

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

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

код, который реализует тот или иной функционал – код репозитория, если идет работа с БД, к примеру. И в этом случае обработчик напротив должен быть максимально близко к месту возникновения исключения.

Не могли бы Вы подробнее описать, что будет делать этот обработчик?

[brewerof]

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

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