BusinessError('Some concrete error')?
ну короч суть в "для каждой ошибки бизнес логики своё исключение" против "одно общее исключение"
Если какие-то ошибки по какому-то критерию «равнозначны» (допустим, должны обрабатываться одинаково) и меняется только сообщение/какой-то код, то второй вариант ок
если тестировать, то не выйдет просто сделать $this->expectsException(), надо будет текст ошибки вытаскивать и сравнивать
Если тебе важен текст ошибки, то да
допустим в коде есть 2 ошибки которые бросают одно исключение. и мне надо проверить что падает именно по причине одной из этих ошибок
сделать два исключения, наследованные от одного, тот момент, где наследование норм...
а вообще попахивает контролем управления через исключения, попробуйте иначе взглянуть на программу
Я рекомендую не использовать исключения для отслеживания результатов принятия решений. Вместо этого создавать объект-результат, который внутри содержит коллекцию статусов, характеризующих результат, а так же любые дополнительные данные необходимые вызывающему коду или юнит тестам. Это более гибкое решение, потому что - позволяет возвращать несколько результатов, полученных за одну проверку; - позволяет возвращать результаты разных типов важности (ошибки, предупреждение, информационные и успешные статусы); - позволяет накапливать такие объекты-результаты при пакетной обработки данных; - позволяет мержить результаты полученные из разных логик принятия решений; - позволяет манипулировать этими объектами-результатами в дальнейшей логике, например, использовать их в сервисах переводов и отображения; - гораздо проще тестировать, описывать наборы данных в дата-провайдерах юнит тестов; По-мимо гибкости, такой подход ведёт к более качественному и понятному коду, позволяет избегать определённых вредных практик, к которым приводит использование исключений там, где им не место, а именно в такой вот бизнес логике со сложными алгоритмами принятия решений.
Обсуждают сегодня