Это утверждение требует более осторожной формулировки:
Код:
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.
Это те исключения, которые просто приводят к падению подпрограммы или программы в целом.
Собственно, они упоминаются:
- Your database is not reachable? There is usually nothing your program can do to fix this
- Your application does not have rights to write in a directory? There is usually nothing your program can do to fix this
- Your hard disk is full? There is usually nothing your program can do to fix this
- You have a SQL error? There is usually nothing your program can do to fix this
И сидеть, скрупулёзно придумывать имя каждому из кейсов выше — это, как правило, пустая трата времени.
Потому что это 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» подразумевается нечто более общее, чем просто глобальный обработчик.
То есть, программа состоит из подпрограмм, и некоторые из подпрограмм могут совершенно справедливо падать «молча» для программы в целом, но с сообщением в лог.
Типичный пример — слушатели событий. Каждый из них может падать, но это не должно приводить к падению всей программы.
