Обработка ошибок, часть 1. Общие принципы.

Большинство начинающих пхп-программистов путаются в обработке ошибок.
Причём путаница происходит оттого, что они смешивают несколько понятий. А именно:
1. Факт ошибки.
2. Сообщение системы об ошибке.
3. Обработка ошибки
4. Информирование пользователя об ошибке.

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

Далее следует несколько простых и очевидных рекомендаций.

Системное сообщение об ошибке - не твой враг, а твой друг. Избавляться от него не надо! Наоборот - надо стремиться получить его всеми силами - оно поможет исправить тебе ошибку.
Не надо просто путать программиста с пользователем.
Если ты разрабатываешь сайт, и пользователь - ты сам, то удобнее смотреть ошибки на экране.
поэтому делаем в настройках сервера
display_errors=on

Если сайт уже работает, и на него заходит куча пользователей, то ситуация меняется в корне.
Во-первых, системные сообщения об ошибках пользователь видеть не должен.
Во-вторых, их как-то должен видеть программист, причём не только когда он сам обращается к сайту, но и те ошибки, которые происходят у других пользователей.
Первая задача решается уже знакомой нам директивой
display_errors=off
вторая - настройкой, которая заставит пхп все ошибки писать в лог, где их потом может увидеть программист.
log_errors=on

С самописными функциями всё просто.
главное - никаких die(mysql_error())!!!
это хорошо на этапе обучения, но никуда не годится на посещаемом сайте!
во-первых, ПОЛЬЗОВАТЕЛЮ эта mysql_error() ничего не скажет.
во-вторых, программист её не увидит.
В-третьих, негоже вообще обрывать вывод сайта на середине.
Поэтому делаем проверку вместо die надо использовать trigger_error()
В результате у нас должно получиться
$query="Select * FROM table";
$res=mysql_query($query) or trigger_error(mysql_error().$query);
Таким образом, сообщение об ошибке выведется туда же, куда выводятся все остальные ошибки, в зависимости от установок, рассмотренных выше.

Из написанного выше становится ясно, что собака не бывает нужна в принципе никогда.
Во-первых, расставить собак во всех местах вероятного появления ошибки просто нереально.
Во-вторых, и самое главное - собака делает НЕ ТО, ЧТО ВАМ НУЖНО! Вы просто путаете вывод сообщения пользователю и информирование программиста об ошибке.
Вам нужно запретить вывод ошибок пользователю? Отлично! ОДИН раз написать display_errors гораздо проще, чем лазить по коду, расставляя собак.
Надо посмотреть сообщение об ошибке? Отлично! Лезем в лог или включаем display_errors, вместо того, чтобы сидеть и гадать на кофейной гуще - где ошибка. Вывод же сообщений мы собакой подавили!

То же само касается директивы error_reporting. Её значение всегда должно быть на максимуме и не меняться от того, где запускается скрипт - как мы помним, за вывод ошибок должна отвечать не она, а display_errors.

Всё. С программистом закончили.
Теперь осталось проинформировать пользователя об ошибке - ведь до сих пор мы заботились только о том, чтобы пользователь не увидел ошибку.
Теперь подумаем, как сделать так, чтобы пользователь увидел дружественное сообщение об ошибке, да ещё и желательно не в разорванном дизайне.
Проще всего это делается с использованием шаблонов.
Ведь при их использовании сначала исполняется весь нужный код, по завершении которого можно проконтролировать успешность его выполнения, а потом выводится шаблон, который, в случае ошибки, можно заменить шаблоном стандартного сообщения об ошибке.
Подробнее об этом можно прочитать в следующей главе: Обработка ошибок, часть 2. Разбор примера. Исключения.