Я прямо влюбился в этих ребят

DevConf 2017 - видео с конференции, успей до 17 июля | Проверенные VDS на SSD в Европе и России

Тема в разделе "PHPWorld - новости из мира PHP", создана пользователем Фанат, 4 июл 2017.

  1. Фанат

    Фанат oncle terrible Команда форума

    Сообщения:
    39.623
    Ваш город:
    Moscow, Russia
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
  2. Вурдалак

    Вурдалак Newbie

    Сообщения:
    5.846
    Ваш город:
    Russia, Moscow
    Adress:
    Moscow, Russia
    Country:
    Location on Map:
    Это утверждение требует более осторожной формулировки:
    Код:
    You should never throw the Exception class directly. Instead, you should consider extending the Exceptionclass or using one of the available sub-classes.
    <...>
    Why is this bad? Because you are preventing the developer to catch specific problems.
    Конкретно \Exception я не кидаю, но я частенько кидаю просто \RuntimeException или \LogicException.
    Это те исключения, которые просто приводят к падению подпрограммы или программы в целом.
    Собственно, они упоминаются:
    И сидеть, скрупулёзно придумывать имя каждому из кейсов выше — это, как правило, пустая трата времени.
    Потому что это unchecked exceptions, которые ловят просто как \Exception (\Throwable), которые не указывают в @throws и, как следствие, стоит понимать, что если ты пишешь catch (DiskIsFullException $e) где-то в произвольном куске программы, то ты делаешь серьёзное предположение, что что-то там где-то глубоко внутри работает с диском — а откуда ты это знаешь, если это не указывается в @throws и не является частью интерфейса?
    Единственное отличие в том, что в логе приятнее видеть конкретный класс, но фактически сообщения + трейса достаточно.

    Вот это утверждение требует коррекции:
    Код:
    So unless you are writing an error handler, or rethrowing the exception, you should always carefully consider what exceptions you want to catch and never try to catch the Exception class.
    Это утверждение имеет смысл, если под «error handler» подразумевается нечто более общее, чем просто глобальный обработчик.
    То есть, программа состоит из подпрограмм, и некоторые из подпрограмм могут совершенно справедливо падать «молча» для программы в целом, но с сообщением в лог.
    Типичный пример — слушатели событий. Каждый из них может падать, но это не должно приводить к падению всей программы.