Профиль пользователя заблокирован сроком с 10 апреля 2022 г. и навсегда по причине: систематические нарушения правил сервиса
Ответы пользователя по тегу Исключения
  • Как выводить свою страницу ошибки для каждого исключения?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    500.blade - это и есть пользовательская страница. Единственное, что нужно видеть пользователю, при ошибке InvalidArgumentException.
    Никакой другой не нужно
    Ответ написан
  • Правильно ли я понял централизованную обработку исключений в PHP?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    В целом правильно, неплохая проработка материала.
    У меня есть только пара замечаний, не относящихся напрямую к централизованному обработчику.

    • error_reporting(E_ALL & ~E_NOTICE); делать не стоит. Если только не приходится работать с адовым легаси, которое сыпет нотисами, лучше отлавливать все ошибки. Учитывая же что в 8-ке обращение к несуществующей переменной станет не нотисом а предупреждением, такая конструкция со временем станет бессмысленной. что означает - ошибки надо исправлять, а не замалчивать.
    • ini_set("error_log", __DIR__ . "/php-errors.log"); будет не очень хорошей идеей, если файл error-handler.php выше корня веб-сервера. Ошибки надо прятать подальше.
    • ini_set('display_startup_errors', 1); - это какая-то дичь, которая кочует из руководства в руководство. Никто никогда этих стартап еррорс не видел, но многие старательно пишут это заклинание у себя в коде. Это по-любому связано с настройкой сервера, и в отладке ошибок поможет примерно ничем.
    • само по себе задание настроек через ini-set ненадежно. Ошибка может случиться до того, как РНР прочитает эту команду. Задавать надо в конфигурации веб-сервера.
    • в теории можно добавить флаг или автоматическую проверку на джейсон запрос. и соответственно кодировать ответ в джейсон. Но это только для криовруких фронтендеров, которые не умеют читать НТТР статусы, а ждут что им все разжуют в джейсоне, и без error: true они не поймут, что была ошибка
    • стек вызовов может быть довольно длинным, и раздувать логи. Можно подумать о более укороченном варианте.


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

    Я только не понял, почему вопрос про error_handler. Что именно смущает?
    Ответ написан
    5 комментариев
  • Правильно ли выбрасывать исключения в бизнес логике?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Ответ на вопрос из заголовка простой: исключение выбрасывается тогда, когда код не в состоянии выполнить работу, для которой он предназначен. Это простое правило, общее для программирования в целом, и безнес логика в этом смысле ничем не отличается от любого другого кода.

    Я бы разделил валидацию и создание заказа.
    Для валидатора ошибки введенных данных - это не исключителная ситуация, а соверешнно штатная.
    То есть можно проверить результат валидации простым условием, без всяких исключений.


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

    Но вот код, который лежит внутри catch(OrderException $ex){ является избыточным. Логирование ошибки и вывод стандартного сообщения клиенту - это то, что должен делать централизованный обработчик ошибок, который в любом случае должен присутствовать в приложении. То есть здесь этот код явно лишний.
    Ответ написан
    8 комментариев
  • Как ловить исключения в нескольких методах?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Вопрос странный. В какую розетку мне воткнуть чайник? В ту что ближе!

    Правильно писать блок try-catch там где надо поймать исключение.
    Если нужно ловить исключение в контроллере - ловить в контроллере.
    Если надо ловить в методе - ловить в методе.
    Если надо ловить любое исключение в программе - либо в глобальном блоке try-catch, либо в эксепшен хендлере.
    Ответ написан
    2 комментария
  • Можно ли таким образом использовать try-catch?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Можно, используется. Но в 99% случаев не нужна.
    В данном случае скорее всего тоже. Ожидать исключения в транзакции - плохая практика. Скорее всего, либо никакие уточнения не нужны, либо данные не были провалидированы до начала транзакции.
    Ответ написан
    2 комментария
  • Структурирование исключений. Что вы указываете в качестве exeption code?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    В этом вопросе перемешаны мухи и котлеты. Вопрос, вроде бы, про некое "структурирование исключений" (то есть, ждешь про иерархию классов), а на самом деле автора интересует вопрос взаимодействия с пользователями и идентификации ошибок.

    Главная неувязка - какая связь между кодом исключения и уникальным кодом ошибки, служащим для идентификации конкретного места в логах? Это совершенно разные сущности, не имеющие ничего общего. Генерацией уникальных кодов должен заниматься обработчик ошибок, ни ни к кодам исключений, ни к самим исключениями, ни тем более к их иерархии это все не имеет отношения.
    Ответ написан
  • Как правильно поступить?

    FanatPHP
    @FanatPHP
    Чебуратор тега РНР
    Нет, ну это ад какой-то.
    Написано же, русским языком:
    - в-третьих, этот код лишает нас возможности обрабатывать все ошибки централизованно, в едином exception handler-е.

    человек читает... и старательно наступает на ровно те же самые грабли:
    для КАЖДОГО запроса, который может вернуть ошибку (то есть вообще для любого) он собирается писать колбасу из try catch на 6 строк.

    Для кого написано про централизованную обработку? Казалось бы - разул глаза, погуглил php exception handler, скопировал по образцу, нарисовал там хоть котиков, хоть слоников, хоть себя без трусов, добавил отправку почты себе поздравление бабушке, соболезнования котику. Все что угодно, но в одном, ОДНОМ месте.
    Ответ написан