Обработка ошибок в коде программ РНР

В данной терминологии диагностические сообщения, которые выдает РНР, также можно назвать кодом восстановления.

Ошибки по своей "серьезности" можно подразделить на два больших класса:

● серьезные ошибки с невозможностью автоматического восстановления. Например, если вы пытаетесь открыть несуществующий файл, то далее обязательно должны указать, что делать, если это не удас

тся: ведь записывать или считывать данные из неоткрытого файла нельзя;

● несерьезные (нефатальные) ошибки, восстановление после которых не требуется, например, предупреждения (warnings), уведомления (notices), а также отладочные сообщения (debug notices). Обычно в случае возникновения такого рода ошибочных ситуаций нет необходимости предпринимать что-то особенное и нестандартное, вполне достаточно просто сохранить где-нибудь информацию об ошибке (например, в файле журнала).

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

1.2.1 НЕСЕРЬЕЗНЫЕ ОШИБКИ

Для обработки нефатальных ошибок, после которых не требуется "персональное" восстановление, в РНР имеется инструмент, называемый установкой обработчика ошибок (или перехватом ошибок; подробнее см. п. 2).

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

1.2.2 СЕРЬЕЗНЫЕ ОШИБКИ

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

В функции-обработчике для восстановления после ошибки можно выполнить всего лишь одно осмысленное действие — это завершить программу.

Главный вопрос при работе с серьезными ошибками — написание кода восстановления. Он должен иметь достаточный контроль над ходом выполнения программы (например, мог выполнять инструкции return или break, а не только лишь завершал программу по exit ()).

1.2.2.1 Прекращение выполнения программы

В случае возникновения серьезной ошибки программа завершает работу по exit() или die().

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

1.2.2.2 Возврат недопустимого значения

Практически все стандартные функции РНР в случае возникновения ошибочной ситуации возвращают false или NULL, а также вызывают trigger_error() для фиксирования диагностического сообщения (его можно потом перехватить при помощи функции-обработчика). Например, функция fopen() при невозможности открытия файла возвращает false, и мы в дальнейшем должны проверить результат на "истинность".

Этот метод имеет три недостатка.

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

● Любое значение, возвращаемое функцией, может быть по смыслу допустимым. Например, стандартная функция unserialize() распаковывает некоторую переменную из ее строкового представления (сгенерированного вызовом serialize()) и возвращает ее исходное значение. Что должна вернуть функция в случае ошибки? Если, например, NULL, то где гарантия, что действительно произошла ошибка, а исходная переменная не содержала просто значение NULL до упаковки?

● Код восстановления приходится постоянно дублировать. Например, если в программе нужно открыть 10 разных файлов, мы будем вынуждены 10 раз проверить возвращаемое функцией fopen() значение. Легко представить, как сильно это "раздует" программу. Еще хуже вы себя почувствуете, если вспомните, что в будущем может понадобиться модифицировать код восстановления: придется делать это в 10 местах.

1.2.2.3 Ненормальное состояние программы

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

Так работают, например, инструменты для доступа к MySQL в PHP: mysql_connect(), mysql_query() и т. д. Вы можете проверить, не вернули ли функции "ложное" значение, а потом использовать mysql_error() или mysql_errno() для получения дополнительной информации. Состояние программы, в котором когда-то ранее произошла ошибка, требующая дополнительного анализа, называют ненормальным. Главный недостаток ненормального состояния в том, что если вдруг произойдет еще одна ошибка, то информация о ней "затрет" предыдущее сообщение. Таким образом, мы вынуждены периодически проверять, не находится ли программа в ненормальном состоянии, и предпринимать дополнительные действия. Это сильно увеличивает код, кроме того, программист может забыть вставить в программу требуемые проверки.

1.2.2.4 Вызов функции-обработчика

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

1.3 ДИРЕКТИВЫ РНР КОНТРОЛЯ ОШИБОК

Уровнем детализации сообщений об ошибках, а также другими параметрами управляют директивы РНР, перечисленные ниже.

1.3.1 ДИРЕКТИВА error_reporting

error_reporting

● Возможные значения: числовая константа (по умолчанию — E_ALL~E_NOTICE.

● Где устанавливается: php.ini, .htaccess, ini_set ().

Устанавливает "уровень строгости" для системы контроля ошибок РНР. Значение этого параметра должно быть целым числом, которое интерпретируется как десятичное представление двоичной битовой маски. Установленные в 1 биты задают, насколько детальным должен быть контроль. Можно также не возиться с битами, а использовать константы. В табл. 1.1 приведены некоторые константы, которые на практике применяются чаще всего.

Таблица 1.1. Биты, управляющие контролем ошибок

 Скачать реферат