Ошибки с помощью Exception или строки?

Question

[durden_tailer]

Доброго времени суток!
Хочу поделиться опытом разработки на PHP/Laravel.

Создал бэкенд для мобильного приложения с json API.
Использую "вместо исключений" почти везде возвращаемые(return) конструкции вида:
[ data => [... тут какие-то данные], 'status' => 'ok' ] либо
[ data => [], 'status' => 'error', 'message' => 'Текст ошибки'].

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

Пробовал кастомизировать исключения и выкидывать их вместо [ data => [], 'status' => 'error' ], но
иногда нужно слишком много кастомных исключений обработать, а это много try-catch, try-finally.

Хочу спросить совета и опыта использования лучших практик Laravel/PHP - делал ли кто-то подобные консепты (велосипеды с квадратными и треугольными колесами)?

Вцелом, выброс исключений смотрится "эстетичнее" в коде. Но это скорее, дело привычки и стиля.
Вообще без них сложно. Слишком много - тоже плохо.

Answer 1

[Максим]

Конечно же в коде нужно использовать исключения. И в тестировании они проще и это просто логично! Если вы используете типизацию в php и вам должен возвратиться объект City, то возвращая строку или массив вы получите ошибки. Тут без исключений уже не обойтись. Поэтому, если вы хотите писать код правильно - вам нужно использовать в домене только исключения!

А try-catch можно инкапсулировать в коде, если не нравится.

Comments

[durden_tailer]

Дело в том, что почти все функции возвращают некий набор данных:
[ 'data' => [.. city, adress, и т.д.], 'status' => 'ok' ]
либо
[ 'data' => [empty array()], 'status' => 'error' ]
Фронтенд получая пустые данные и состояние ошибки, сам решает, что с этим делать.

Получился своего рода "унифицированный" язык общения между функциями и классами.
Нежели возвращать либо City либо throw new Exception NotFoundCity или CityServiceUnreachable

Но конечно - это все же велосипед.

Да и в тестировании исключения проще - соглашусь, Вы правы.

[Максим]

durden_tailer, только эксепшены) Если говорить об api и эксепшенах на симфони, то try-catch можно вынести там так Симфони сама будет отображать ошибки в api как надо.вы можете сделать что-то подобное в ларавел и вынести из кода обработку ошибок.

[durden_tailer]

Максим, Да я понимаю :)
В Laravel то же самое.
Есть Global ExceptionHandler , который перехватывает исключения на верхнем уровне, представляя их как JSON (для API) или как HTML.

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

[Максим]

durden_tailer, ну вот) Я точно не знал как в Laravel, поэтому не стал советовать. В домене вызываете свои Domain ошибки или написанные собственные. Лучше работать с типизацией. Избавляться от if else. Это только усложняет код. А switch лучше вообще воздержаться. Нужно понимать точно когда он действительно нужен. Но это не по теме) Только исключения!) Если у вас код ошибки выводит строкой - подумайте об рефакторинге такого когда)

[durden_tailer]

Максим, благодарю!
Уже подумал, начал рефакторинг (в связи с чем и задал вопросы на Тостер).
Пока с переменным успехом :)

[Максим]

durden_tailer, ну тогда удачи!)

Answer 2

[Alex Wells]

Дополню ответ Максим :

В своих проектах я всегда начинаю с того, что пишу какой-то базовый Exception, типа AppException, который всегда ловится Exception Handler'ом и отдает инфу юзеру. Он же висит в списке $dontReport, так как это всегда ожидаемая мной ошибка, о которой я не хочу быть уведомленным.

Собственно если я хочу, что бы ошибка попала в логи, потому что такой ситуации не должно быть - обычные встроенные эксепшены типа AssertionError, IllegalArgument, LogicException и так далее. Если не хочу - AppException и наследованые от нее.

Тогда почти везде в контроллерах пропадают try-catch'и за счет exception handler'а.

Comments

[Максим]

Как вариант) Вы умеете работать с классами и наследованием) А то тут есть такие, кто говорит о 100 эксепшенах)

Но полностью App эксепшен лучше не использовать. Их лучше разделить на доменный слой, ошибка базы (репозитория), request и так далее. Но ловить можно не все.

[Alex Wells]

Максим, это и есть доменная ошибка) Все, что не относится напрямую к бизнес логике, никак не привязано к ней - вместо этого я кидаю кастомные ексепшены, и, если нужно, ловлю и перебиваю App вариантами.

По сути, это DomainException.

[Максим]

Alex Wells, тогда все верно советуете) Не понял сразу может