Существует ли какой-то общепризнанный подход к обработке ошибок в контексте API, где его можно посмотреть?

Question

[Роми]

Наткнулся на такую вот интересную статью:

https://cerwyn.medium.com/laravel-generalizing-api...

но совершенно не уверен, насколько такой подход соответствует лучшим практикам. Вы можете что-то сказать по этому поводу?

В целом вопрос стоит так:

- Хочу построить для API на Laravel какую-то систему обработки ошибок через Exceptions, но не хочется велосипедить.

Где можно посмотреть какие-то общеизвестные и общепризнанные подходы к вопросу?

Спасибо.

upd.: по мотивам каментов пример для понятности:

User::find(100500)->someMethod();

Постоянно приходится иметь дело с какими-то такими вещами, когда модель может быть не найдена, и оно либо весь стек вывалит если дебаг включен, либо краткое и емкое

{
    "message": "Server Error"
}

если выключен. а хочется нечто среднее, что можно отдать на фронт, понятное, но без лишней информативности.

Я раньше обычно писал всякие проверки прямо в теле функции, либо optional() использовал, либо еще что-то в этом же духе. Response руками делал для каждого случая.

Но может это как-то можно решить через кастомизацию Exceptions? Как-то автоматизировать более-менее?

Руководства которые я нашел в сети - достаточно куцые. По крайней мере, в контексте моего понимания данной области.

Comments

[jazzus]

Это типа лайвхак, как трейтами пользоваться? Очень интересно.

[Роми]

jazzus, это сарказм или нет? ) По буквам не всегда понятно :)

[jazzus]

Роми, в статье бред и говнокод. Ларавел это фреймворк для веб приложений. Наверное, там задумывались о возврате ошибок.

[Роми]

jazzus, я апдейт написал к вопросу для понятности.

User::find(100500)->someMethod();

если юзер не найден - то хочется на фронт отдавать ответ с кастомным каким-то текстом, а не просто

{
    "message": "Server Error"
}

как такие вопросы обычно разруливают, если у нас таких случаев по коду предполагается много?

[jazzus]

Роми, данное сообщение Ларавел возвращает автоматом

[Роми]

Mellorn, дело не в ресурсе, дело в том, что по ходу обработки запроса скрипт обратился к методу несуществующего экземпляра модели, это никак не 404.

[jazzus]

Роми, 500 ошибка это 500 ошибка, инфа там для юзера одна - ошибка сервера. Подробности для разработчика в логе. Код ответа есть на фронте можно менять дизайн как хочешь. Или здесь https://laravel.com/docs/8.x/errors#rendering-exce...

[jazzus]

Mellorn, там вызов someMethod на null) Вместо model binding или findOrFail

[Роми]

Mellorn, мы не ресурс запросили, а результат выполнения метода someMethod() - это другое (Ц) )))

[Роми]

...хотя это и может быть ресурсом, если например

GET /api/users/100500/something

[Роми]

Mellorn, ну, так о том и речь, что эксепшн - это просто способ сказать об этом клиенту. Один из. Для меня эта тема в данном ракурсе - новая, я эксепшены активно не использовал. Вот и ищу сейчас какие-то заведомо годные решения, чтобы посмотреть, как оно вообще делается в природе.

[jazzus]

Роми, 500 ошибки вообще нет никакого смысла расшифровывать. Бред. Их вообще быть не должно. Максимум написать ошибка сервера. Ну или включай дебаг тру на проде и расшифровывай по полной. А для 404 достаточно шаблона https://qna.habr.com/q/52852525252 или обрабатывать как написано в документации, а не в каких-то левых статьях.

[Ичи Ня]

если правильно помню в php8 стала возможна конструкция User::find(100500)?->someMethod(); которая выдаст просто null.. а потом просто проверяем, если нул - сущность не найдена

Answer 1

[Ипатьев]

С дополнением вопрос стал значительно понятнее.

Разумеется, "решить" нельзя.
Потому что никакой хендлер не заменит программиста.
В случае с generic exceptions хендлер не в состоянии узнать, это у вас база отвалилась на запросе, или просто код кривой, который не проверил существование объекта при обращении к методу.

Поэтому если надо проверить существование юзера и вернуть ошибку, то это и надо сделать. Причем как бы ещё не на этапе валидации.

А вот response руками делать - это лишнее. Куда проще кинуть кастомное исключение. Которое уже будет поймано хендлером и отрендерено в зависимости от типа, как это показано в статье.

Comments

[Роми]

Ну, в целом, да, я сейчас тоже примерно так вижу :)

Но все равно хотелось бы посмотреть на какой-то эталонный код.

Ко всему прочему, не совсем ясно - СКОЛЬКО понадобится таких самописных эксепшенов, и как их упорядочить/структурировать.

Понятно что оно потом с опытом придет)) но у меня как обычно: проект надо делать прямо сейчас ))) и нужны готовые шаблонные решения.

Answer 2

[jazzus]

В Ларавел все коды с ошибками автора статьи высылаются автоматом при использовании форм валидации и апи ресурсов.

Answer 3

[ThunderCat]

User::find(100500)->someMethod();
Постоянно приходится иметь дело с какими-то такими вещами, когда модель может быть не найдена, и оно либо весь стек вывалит если дебаг включен, либо краткое и емкое

По идее просто обернуть трай-кэтч и отдать ошибку, НО! В данном случае, так как вы предполагаете "наличие пользователя или ошибка", правильнее использовать не find а get, тогда вывалится ексепшн про отсутствующий объект.

Comments

[Роми]

хорошая подсказка! спасибо!

[Роми]

правильнее использовать не find а get, тогда вывалится ексепшн про отсутствующий объект

однако не вывалился :)

к тому же get() отдает не объект а коллекцию.

а если запросить [0] - дает эксепшн на несуществующий оффсет :)

ладно, не суть, все решаемо ))

[Ичи Ня]

Хм.. есть ведь методы на подобии $flight = Flight::findOrFail(1)

Answer 4

[Надим]

Чем вас не устраивает такой формат?

{
   'success': false,
   'message': 'Ошибка такая-то'
}

Comments

[Ипатьев]

Его устраивает такой формат. Вопрос совсем не про это.

Answer 5

[Роми]

Ну, возможно, вот этот текст является ответом на изложенную проблему:

https://laraveldaily.com/laravel-api-errors-and-ex...

по крайней мере, понятно, что автор задавался тем же самым вопросом, что и я :)

Но опять-таки, лично у меня нет 100% уверенности, что это именно Best Practice.

Может кто-то из более компетентных выскажется насчет?