Исключение != ошибка

Неделя исключений на хабре?

Например, если мой движок не может подключиться к БД, то это ошибка. Всё. Точка. Без БД сайт не работает, и я не могу с этим ничего сделать. Поэтому я вызываю ales_kaput() и trigger_error()

А что вы будете делать, если в будущем вы решите добавить какую-нибудь логику в обработку конкретно этой ошибки? В какое место будете ее вставлять? Будете править логику подключения к БД?

Исключения != ошибка не только в PHP

Теперь думаю, может написать статью «Переменная != файл» или «Процессор != суслик»?!

Может я что-то упустил, но ведь это не новость и не ценное наблюдение. Более того, довольно сложно найти литературу в которой «Исключение = ошибка». Или читать уже совсем не модно и до всего доходим методом «ого, а так тоже можно!»?

> исключения — это конструкция языка позволяющая управлять потоком выполнения
> Их основное предназначение: пробрасывать по каскаду.
> ошибка — не поправимая ситуация;
>исключение – позволяет прервать выполнение каскада функций и пробросить некоторую информацию. Что-то
> вроде глобального оператора return. Если у Вас нет каскада, то вам достаточно использовать if или return.

Это феерично.

Уважаемый, вы бы хотя бы википедию посмотрели перед тем как херню нести.

P.S. При всем моем уважении к веб-разработчикам, но почему такое всегда в блоге PHP?

Полностью не согласен с точкой зрения автора. Какие-то двойные стандарты: для библиотек, мол, всегда исключения, т.к. она должна быть гибкой, а для каких-то «не библиотек» — ошибки. Это для вермишели чтоли? Иначе как разделить код на библиотеку и не библиотеку? Если пишем максимально code reuse'абельно, то практически любой код можно считать библиотекой, которая может использоваться где-то в другом месте. И вполне возможно, что в этом другом месте та фатальная неисправимая ошибка вовсе не является фатальной и неисправимой.

Тут есть три момента:
1. Спор о том, что лучше — исключения или коды возврата, абсолютно не нов, и PHP тут не при чем.
2. В той же яве ошибки — это разновидность исключений, сигнализирующих о неисправимой проблеме.
3. Использовать процедурный (коды возврата) или объектно-ориентированный стиль (исключения) обработки исключительных ситуаций — дело вкуса каждого.

Теперь я чётко знаю, где использовать trigger_error(), а где throw new Exception()

У меня для тебя плохие новости, бро.

if ($x === 0) {
throw new Exception('Делить на ноль нехорошо');
}

А проверять float на строгое равенство — еще хуже.

Я бы выпилил бы все эти trigger_error и ядра PHP.

Когда-то я писал на PHP и очень удивлялся, почему же все эти ошибки не ловятся моим catch-ем. Но потом я перешёл на нормальные языки программирование, и мои волосы стали гладкими и шелковистыми.

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

В объектном программировании я стараюсь руководствоваться принципом: если на выходе метода должен быть объект — то только объект или exception. Никаких 0/false/null.

Исключение должно порождаться лишь нарушением нормального выполнения кода. Т.е. в случае ошибки. Вашей ошибки, системной, или ошибки пользователя (т.е. в итоге — вашей), исключающей возможность нормального продолжения работы линейного кода вашего приложения.

Более того, если Вы используете библиотеку н-р в качестве адаптера (Zend_Db) и в вашем сервисном слое она вызывается, Вы, как хороший разработчик, не должны позволять этому исключению просто так провалиться в контроллер, Вы должны перехватить это исключение, обернуть его в свое и пробросить дальше новое, которое будет содержать в себе тело исходного исключения. Потому что когда-нибудь вы захотите использовать вместо Zend_Db, например, чистый PDO или Doctrine, и чтобы Вам не перелопачивать весь код на предмет перехвата исключений Zend_Db_Exception, а ограничиться лишь теми слоями, которые у Вас непосредственно Zend_Db и используют. Именно для этого в PHP 5.3 в конструкторе исключений появился третий параметр типа Exception, который реализует некоторое подобие приемственности.

Что касается использование использования исключений для управления процессом выполнения — эта идея отвратительна по своей сути и противоречит хорошему тону программирования, и, как уже написано выше, является сходным по сути с безусловным оператором GOTO.

Много полезного выше уже написали, добавлю еще.
Мне всегда казалось, что в ООП исключение — это часть интерфейса того или иного метода или класса.
Основная его ценность, что если мы знаем, как его обработать, то мы должны его обработать (например, залоггировать куда-нибудь) и продолжить выполнение кода, либо прокинуть выше, либо и то и другое вместе.

Хотел пример написать, но даже простой пример нужно довольно серьёзно расписывать, ленюсь в общем. Лучше порекомендую почитать классическую литературу по ООП: про шаблоны проектирования, про рефакторинг и тому подобное. Неплохой список здесь: wiki.agiledev.ru/doku.php?id=books. На этом же сайте можно найти и неплохие статьи на русском. Чтение данной литературы вкупе с постоянной практикой позволит со временем раз и навсегда забыть о trigger_error и error_handler (который, тем не менее, пригодится, чтобы превратить всякие PHP_WARNING в нормальный Exception). На мой взгляд — это вообще наследие четвёртого PHP, которое необходимо только для совместимости.

И да, не стоит каждую ошибку слать себе на email, если это не какой-то внутрикорпоративный проект. Попадет говнокод на сервер (а он обязательно попадёт :) ) и засыпет ящик спамом. Хотя, я тут уже преждевременно оптимизирую ваш способ обработки ошибок :)

Приложение не смогло подключиться к БД и как это обработать неизвестно, сворачиваем лавочку, ок, чем в этом случае trigger_error и set_error_handler кардинально отличается от throw new Exception и set_exception_handler (try/catch верхнего уровня) за исключением того что во втором варианте исключение при необходимости можно поймать… может лучше перебдеть чем недобдеть, мм? :)

Нравится мне вот такая картинка. Из Java, конечно, но все равно она к месту:

По вашей логике, некоторые участки кода в праве решать как вести себя всей системе (падать ли ей насмерть или, так уж и быть, позволить себя обработать).

Что-то я не ощутил разницы между trigger_error() и throw new RuntimeException(). И там, и там идёт прерывание кода(нотисы не в счёт, с ними разговор короткий). И там, и там идёт последующая обработка: показать страницу с ошибкой, записать в лог, уведомить заинтересованных. В чём всё-таки разница?

Более точно суть статьи отражал бы заголовок
Исключение !== ошибка

а потом добавляем вызов функции d после c и долго думаем, почему же она не вызывается. а потом выяснив, что какой-то умник решил «пробрасывать управление через каскад» добавляем такого рода защитный код:

function b()
{
try{
c(99);
} finally {
d(100);
// и остальное тело функции
}
}

Я считаю наиболее правильным, когда все ошибки являются исключениями. Как в питоне, js, c# etc…

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