Объект ошибки в Laravel. Express советы
HTML-код
- Опубликовано: 4 окт 2024
- Этот ролик будет посвящен обработке ошибок и не совсем стандартному для нас подходу. В классическом подходе для PHP разработчиков это не объект с ошибкой а исключение.
🎁 Для вас есть подарок, забирайте - cutcode.dev/l/... 🎁
#Expressсоветы#laravel#cutcode
---------------------------------------------------------------------------------
🚀📹👨🏫 Как насчет прокачки своих навыков с помощью наших обучающих видеокурсов по web-разработке? Переходи на мой сайт 👇
learn.cutcode....
❗️❗️❗️Присоединяйся к нашему комьюнити в телеграм - там и советом помогут и много интересного - cutcode.dev/l/...
---------------------------------------------------------------------------------
📹 делитесь этим видео с друзьями:
• Объект ошибки в Larave...
🔔 подпишитесь на RUclips-канал: www.youtube.co...
📼 Курс по Laravel с нуля:
• Курс по Laravel 8 обуч...
Объект ошибки в Laravel. Express советы
---------------------------------------------------------------------------------
🔗 наш сайт: cutcode.dev/?u...
📱 Наш telegram-канал: t.me/laravel_c...
Интересно. А поясни какой Профит в этом. Уже нет строго одного возвращаемого типа, теперь результат нужно ещё проверять (как минимум знать что его нужно проверять). Если вызовов будет много и в каждом ответе проверять. А если ошибка не на первом уровне вызова, тогда как? Проверять и снова возвращать ошибку дальше?
Exception преимущество, что вызвал где угодно и сделал единственную обработку в глобальном хендлере.
Если напишешь о профите такого подхода, будет неплохо
И вместо понятного исключения мы получаем метод который возвращает два типа и его нужно оборачивать в три условия: true/false, isError и Exception
С исключениями всё понятно. Есть основной бизнес процесс который должен выполняться. И есть исключительные ситуации которые возвращают исключения. Всё. Error это похоже нечто среднее между исключением и response. Причем всё это происходит из-за смешения слоя сервисного с бизнес логикой и пользовательского с респонсами.
Вынести условия в сервис, тестировать сервис. Оставить в экшне вызов сервиса, try/catch и response. И всё.
Плюс try/catch уезжает в родительский экшн и тогда обычные экшены возвращают даже не респонсы а массивы или свои типы/DTOшки. Так экшны даже не имеют лишней зависимости в виде респонса , но зависят от родительского экшна который знает что вернуть и как среагировать на исключение
Когда нечего делать начинаешь придумывать свой велосипед 🙃
Целесообразность такого подхода бесконечно близка к нулю, имхо
try/catch явно проще и быстрее при написании и точно понятнее при поддержке кода другими разработчиками, а главное во всех ситуациях, где надо вернуть, вывести, залогировать ошибку, try/catch вполне достаточно.
Похожий подход в Битриксе)
Только там объект Result, который может быть успешным или нет.
И с этим не очень удобно работать
Просто поддерживаю все комментарии выше.
Но спасибо что поделился идеей, но как по мне она не живучая и добавляет лишнюю логику когда с исключениями все намного проще и понятней
Может я чет не понял, но не вижу профита тащить ошибку через всю цепочку вызовов, проще выкинуть исключение и перехватить на любом уровне или через эррор хэндлер ларки.
Такая практика могла бы быть, в каких-нибудь Java или C#, когда код не умирает, и он должен обеспечивать очень даже HiLoad. И мы бы сам объект Error взяли бы из пула. Там затраты на Try Catch очень серьезны и ресурсозатратны, а в плане PHP это вроде как, ну такое себе. Я могу быть не прав.
P.S. В плане когда Try Catch над одним методом, а не ожидания от него Error. Тут в PHP по затртатам минимум КМК.
Какой-то странный паттерн по типу WP_Error. Каждому свое конечно, но я когда после wp переходил на лару не мог нарадоваться исключениям. Намного удобней чем работать с простым объектом. WP и в го кстати оно логичней смотреться, потому что там не про ооп
Спасибо! С octane+RR корректно будет работать?
@@EscapefromWunderland-jz2yc конечно
Вообще исключения лучше использовать когда что-то пошло не так и всё должно свалиться с 500 и записаться в лог, а ErrorObject где нет аварийной ситуации. Так и логи будут чистыми и структура данных при ошибке. Можно и не парясь в ResultObject затолкать поле errors или скомбинировать и в errors записывать список ErrorObject.
Последний в php редко понадобился бы, это скорее для языков где есть перегрузка. Тогда в зависимости от типа ErrorObject вызовется нужный перегруженный метод.
Например на java в шаблоне "посетитель". Мы делаем что-то, получаем List. У нас есть наследники ErrorObject: FieldError, EndOfEntropyError и InvalidOperationError, у каждого свой набор свойств. И тогда мы сможем сделать в классе ErrorObserver методы: send(FieldError error), send(EndOfEntropyError error), send(InvalidOperationError error). В каждом будет работа со всеми свойствами каждого конкретного error по своему без необходимости подводить их под один интерфейс.
Лучше try catch. В go понятно, там на этом весь яп построен.
Задумывался о синтаксисе в языке, который будет указывать какое исключение может выбрасываться в методе или в функции, чтоб клиент его вызывающий мог знать, какое исключение надо обрабатывать или бросать дальше.
Насчет такого подхода не уверен.
так PHP это и умеет
...catch (ApplicationException $exception){...}
Не бери такое на вооружение.
Сам подумай, что нарушает метод, который возвращает несколько типов. Ну а вдруг ты еще где-то чего-то нахватаешься и будешь возвращать три разных типа.