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

Проверенные VDS на SSD в Европе от $4 и России: Датацентр №1 от 199руб

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

  1. Фанат

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

    Сообщения:
    39.716
    Ваш город:
    Moscow, Russia
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    Adelf и grigori нравится это.
  2. Вурдалак

    Вурдалак Newbie

    Сообщения:
    6.025
    Ваш город:
    Russia, Moscow
    Address:
    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» подразумевается нечто более общее, чем просто глобальный обработчик.
    То есть, программа состоит из подпрограмм, и некоторые из подпрограмм могут совершенно справедливо падать «молча» для программы в целом, но с сообщением в лог.
    Типичный пример — слушатели событий. Каждый из них может падать, но это не должно приводить к падению всей программы.
     
    grigori нравится это.
  3. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
  4. grigori

    grigori ( ͡° ͜ʖ ͡°) Команда форума

    Сообщения:
    6.739
    Ваш город:
    Stormwind
    Address:
    Scottsdale, United States
    Country:
    Location on Map:
    Согласен с @Вурдалак, разные модули пишутся в разные годы, и обработка ошибок может требоваться совершенно разная.

    Пример: надо принять большой файл и перенести его в хранилище put-запросом, а при сбое хранилища - положить его по ftp в резервное хранилище. Естественно, падать придется, и делать это нужно только сервису, а модель должна выжить.
     
  5. AnrDaemon

    AnrDaemon Продвинутый новичок

    Сообщения:
    4.098
    Ваш город:
    Moscow, Russia
    Address:
    Moscow, Russia
    Country:
    Location on Map:
    @grigori, осталось подстановку идентификаторов добавить.