Comments 5
Я считаю, что данная статья помогает нам развивать навыки для IT, но то, что сказал Иисус, можно немного поспорить. В данный момент, сейчас идет век IT технологий и то что, сейчас идут большинство сил на IT технологии. В данный момент, человечество разрабатывает новые технологии, программы и тд. И сейчас, обычный человек не сможет прожить время без телефона хотя бы 10-15 дней, потому что, мы уже привыкли к гаджетам и у нас там хранится наша база данных или проще "наши данные", по типу банковские карты и тд. Чтобы не погубить мир IT, мы должны развиваться и продвигать наше IT, для совершенствования!
автору надоело отлавливать тонну кастомных исключений между слоями приложения
...и поэтому он решил написать тонну неубираемого кода по обработке ошибок.
Удобство исключений в том, что в 90% случаев их ловить не обязательно. То есть в коде нет вообще никакой обработки ошибок, ни с try, ни без. А
конструкция по типу
try { .. } catch (Exception $e) { ..$e->getMessage() }
-- это очевидный говнокод, с которым надо бороться не переменой синтаксиса (чтобы теперь на каждый чих писать не try, а if ($result->error)), а выпиливанием бессмысленных try...catch из кода.
Просто удивительно, как автор не замечает этой иронии. Это напоминает мне историю с logicless шаблонами: придумываем несуществующую проблему, потом придумываем гениальное решение для неё, получаем код хуже исходного, и ничтоже сумняшеся пишем победную статью, в которой заявляем полное превосходство своего метода над существующим.
Да нет, напротив, далеко не гениальное решение, не заменяющее (и не пытающееся это делать там где не надо) способ обработки ошибок, предусмотренный самим языком.
По задумке использование такого объекта уместно при составлении логической цепочки по типу: здесь данные взял + проверил, здесь их сохранил + проверил результат сохранения... Если ваш контроллер, юз кейс, да как его не назовите выполняет все эти операции, и вы чётко понимаете, когда какая из них заканчивается провалом - да, конечно, создание нового объекта ответа избыточно.
Но если всё резделено на отдельные репозитории, всё переиспользуется по сотне раз в разных местах приложения, хочеца-не хочеца нужно будет вводить что-то подобное "единому стандарту ответов" для передачи данных между слоями.
Это не просто переход с try на if, это переход на явное выполнение цепочки запросов (как это изначально и было сказано в статье).
В слоях где сосредоточена главная часть приложения и важна последовательность выполнения операций - это более чем удобно.
В какой-то мере я с вами согласен. Но вот не надо было пол-статьи писать про то, какая бяка эти исключения. Потому что решение выглядит не составлением логической цепочки, а борьбой с try..catch.
Плюс, если вы "не против" "предусмотренной" обработки ошибок, то надо было четко описать их сосуществование. А сейчас статья выглядит как "давайте сделаем из пыхи голанг в плане обработки ошибок", а "предусмотренная" обработка сводится к всё тому же try-catch вокруг любого вызова, который может выбросить исключение.
Согласен, мог больше внимания уделить объяснению удобства составления цепочек с помощью такого контракта, не отказываясь полностью от исключений, просто выбрасывая их при фатальных ошибках.
Мог сказать про централизованный обработчик ошибок где-то в бутстрапе, убирающий необходимость try...catch-ить там где не надо.
И свести всё к тому, что с какой стороны не посмотреть, явная обработка ошибок (построенная не на if..else, а на методах по типу .then, .map, .catch и т.д.) лучше для восприятия логической цепочки людьми.
Суть в том, чтобы сделать ошибки частью возвращаемого типа, по аналогии с растом, хаскеллом или десятком других языков. Но в php всё держится на исключениях, там где-то внизу выбросим, потом наверху всё равно всё поймается, а в контроллере мы будем расчитывать на идеальный случай, когда все операции вернули то, что надо...
Вариант конечно живой, но есть и альтернатива.
No exceptions культ — Rift Miniframework