Почему, кроме того что «кто-то там уже придумал» рекомендуют под каждый эксепшен писать отдельный класс? Тут есть сложность вопроса, но, выбрать проще чем простой или "тупой" в списке не было, извиняйте) Я всё до конца понять не могу, почему методы стандартного PHP exception, такие ну как бы это сказать - неудобные? Я слышал многие мнения по этому поводу, но почти все они отталкиваются от того что "люди уже придумали, тебе нужно просто делать как уже придумали".Когда я опираюсь на эту фразу, я вспоминаю тысячи библиотек переписанных с нуля, потому что люди запилили либу, кинули в сеть и потом - там комьюнити засрало, тут он просто не знал и хотел на вакансию, здесь ни с кем не советовался, а тут просто родил, потому что устал.standart: throw new \HttpException500('Text'); // и array вообще нельзя throw new \LogicException('Wtf? There is an ENGLISH string?'); // перевести? болт. array вообще нельзя throw new \InvalidArgumentException('Wtf? There is an ENGLISH string?'); // перевести? болт. array вообще нельзя throw new \MyLibrary\InvalidArgumentException('Wtf? There is an ENGLISH string?'); // перевести? болт. array вообще нельзя Почему не рекомендуется вот так?throw (new \Ex(\MyLibrary\MyClass::ERR_NOT_FOUND))->data($array); throw (new \Http(500))->data($array); throw (new \Flash('validation.error', '@application.err.phrase', $placeholder1, $placeholder2))->data($array); throw (new \Invalid('login', 'rule_login', $placeholder2))->data($array); Понимая, что само сообщение вряд ли нужно ребятам которые следят за тысячей серверов, то приходит мысль как-то так использовать стандартный эксепшенthrow new \InvalidArgumentException(json_encode((array) $data)); чтобы в принципе понять хотя бы что пришло куда ушло Дело не столько в общем познании, а в том, что эти эксепшены нужно ловить, и поскольку их ловля по тем источникам где я читал происходит чуть ли не в контроллере, который есть частный случай, то выходит что я в разных экшенах ловлю одни и те же эксепшены и каждый раз пишу "залогировать. перевести. показать. спрятать" и в каждом суко файле. Сначала я видел в фалконе, они там взяли вокруг программы написали один-единственный трайкетч, который выполняет функцию. Если вернулось в false - считается что поймано. Но это в любом случае не позволяет вернуться на то место где легла программа, она заканчивается, просто не критически при таком подходе. Из плюсов это дает возможность навесить несколько обработчиков а ля ивент. Из минусов - если внутри этого ивента опять произойдет эксепшен то на этот раз все ляжет. причем с фаталом. Меня просто беспокоит, что эксепшен кидается (может быть брошен и будет брошен) методами например по итеративному обходуforeach ($dto as $field => $value) { $this->processString($value); // @throws $this->processInt($value); // @throws $this->processArray($value); // @throws } Дядя Фаулер топящий за ООП и архитектуру приложений когда ему такое принесли слова быстро нашел. Вы говорит неправильно используете эксепшены (ну разумеется, не правы мы, но не стандарт). Тут нужно ErrorBag делать проще говоря массив с ошибками собирать. Правильно. Только прога кидает эксепшены и ей не до массива с ошибками ваще. Если вдруг где что - критикал на пол экрана... Что мне вчера обьяснил Иван Шумов (очень умный кстати мастер своего дела, редко таких встречаю): 1. системы логирования собирают логи по имени класса эксепшена, чтобы группировать их в неких своих админ-панелях, где в выпадающем списке по имени класса можно как-то понять, что произошло 2. в документации есть способ написать @throws и при беглом обзоре по бумагам понять что осторожнее, сие кидает ошибку и прога может рухнуть 3. немного непонятный мне пункт - другая система пришлет тебе эксепшен, который ты не готов обработать если делаешь по своему. не совсем понятно как другой скрипт даже не то что система может прислать мне эксепшен, если там куча компьютеров - то они обмениваются сообщениями через бас, а не эксепшенами Можете объяснить мне-дурачку?В лучшем случае конечно - как переводы делать эксепшенов без необходимости в конкретном трайкетче каждый раз писать "переведи переведи переведи", или хотя бы просто - какого черта под каждую ошибку пишут новый класс? Раньше же делали const ERR_NOT_FOUND, и её можно было хочешь return, хочешь throw, хочешь в ErrorBag - куда угодно, неймспейс не нужен был потому что ошибки лежали в интерфейсе самого класса, который их кидает. Почему вдруг классы поперли?
Существует несколько причин, почему рекомендуется создавать отдельный класс для каждого типа исключения:
Улучшение читаемости кода: Создание отдельного класса для каждого типа исключения позволяет легко понять, какого рода ошибка произошла, по имени класса исключения.
Управление иерархией исключений: Создание иерархии классов исключений помогает организовать их в структуру, что может быть полезно при обработке ошибок.
Расширяемость: Создание отдельного класса для каждого типа исключения позволяет легко добавлять новые виды ошибок и расширять функционал.
Что касается стандартных исключений PHP, они действительно могут казаться неудобными из-за ограниченности сообщений об ошибках и отсутствия возможности передать дополнительные данные. Однако, есть способы обойти эти ограничения, например, создавать собственные классы исключений с методами для передачи данных.
Использование методов, которые кидают исключения, может быть удобным в некоторых случаях, но это может привести к необходимости обрабатывать исключения в каждом месте вызова методов. Подход с созданием отдельных классов исключений может упростить обработку ошибок и улучшить структуру кода.
Если вам не нравится создание нового класса для каждой ошибки, вам не обязательно следовать этому совету. Однако, стоит учитывать преимущества, которые могут быть получены от такого подхода. В конечном итоге, выбор зависит от конкретных потребностей вашего проекта и вашего стиля программирования.
Существует несколько причин, почему рекомендуется создавать отдельный класс для каждого типа исключения:
Улучшение читаемости кода: Создание отдельного класса для каждого типа исключения позволяет легко понять, какого рода ошибка произошла, по имени класса исключения.
Управление иерархией исключений: Создание иерархии классов исключений помогает организовать их в структуру, что может быть полезно при обработке ошибок.
Расширяемость: Создание отдельного класса для каждого типа исключения позволяет легко добавлять новые виды ошибок и расширять функционал.
Что касается стандартных исключений PHP, они действительно могут казаться неудобными из-за ограниченности сообщений об ошибках и отсутствия возможности передать дополнительные данные. Однако, есть способы обойти эти ограничения, например, создавать собственные классы исключений с методами для передачи данных.
Использование методов, которые кидают исключения, может быть удобным в некоторых случаях, но это может привести к необходимости обрабатывать исключения в каждом месте вызова методов. Подход с созданием отдельных классов исключений может упростить обработку ошибок и улучшить структуру кода.
Если вам не нравится создание нового класса для каждой ошибки, вам не обязательно следовать этому совету. Однако, стоит учитывать преимущества, которые могут быть получены от такого подхода. В конечном итоге, выбор зависит от конкретных потребностей вашего проекта и вашего стиля программирования.