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

Чаще всего встречается значение 7 (1+2 + 4), или, что то же самое, E_ALL ~ E_NOTICE (здесь оператор ~ означает побитовое "исключающее ИЛИ"). Оно задает полный контроль, кроме некритичных предупреждений интерпретатора (таких, например, как обращение к неинициализированной переменной). Часто это значение задается по умолчанию при установке РНР.

Если вы разрабатываете скрипты на РН

Р, первое, что вам стоит сделать, — это устанавливать значение error_reporting равным E_ALL или даже E_ALL | E_STRICT, т.е. включить абсолютно все сообщения об ошибках.

Хотя в уже имеющихся сценариях (включая популярные системы phpBB, phpNuke и т. д.) это, скорее всего, породит целые легионы самых разнообразных предупреждений, не стоит их пугаться: они свидетельствуют лишь о недостаточно хорошем качестве кода.

Режим E_ALL очень помогает при отладке скриптов. Существуют распространенные ошибки, над которыми можно просидеть не один час, в то время как с включенным режимом E_ALL они обнаруживаются в течение нескольких минут.

Лучше всего держать в файле php.ini максимально возможный режим контроля ошибок —E_ALL или даже E_ALL E_STRICT, т.е. включить абсолютно все сообщения об ошибках, а в случае крайней необходимости отключать его в скриптах в персональном порядке. Для этого существует три способа.

Способы отключения режима контроля ошибок:

● использовать функцию error_reporting(E_ALL~E_NOTICE);

● запустить функцию ini_set("error_reporting", E_ALL~E_NOTICE);

● использовать оператор @ для локального отключения ошибок.

1.3.2 ДИРЕКТИВА display_errors

display_errors

log_errors

● Возможные значения: on или off.

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

Если директива display_errors установлена в значение on, все сообщения об ошибках и предупреждения выводятся в браузер пользователя, запустившего скрипт.

Если же установлен параметр log_errors, то сообщения дополнительно попадают и в файл журнала (см. ниже директиву error_log).

При отладке скриптов рекомендуется устанавливать display_errors в значение on, потому что это сильно упрощает работу. И наоборот, если скрипт работает на хостинге, сообщения об ошибках нежелательны — лучше их выключить, а вместо этого включить log_errors.

1.3.3 ДИРЕКТИВА error_log

error_log

● Возможные значения: абсолютный путь к файлу (по умолчанию — не задан).

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

В PHP существуют два метода вывода сообщений об ошибках: печать ошибок в браузер и запись их в файл журнала (log-файл). Директива error_log задает путь к журналу.

1.4 УСТАНОВКА РЕЖИМА ВЫВОДА ОШИБОК

Для установки режима вывода ошибок во время работы программы служит функция error_reporting().

int error_reporting([int $level])

Эта функция устанавливает "уровень строгости" для системы контроля ошибок РНР, т. е. величину параметра error_reporting в конфигурации РНР.

Рекомендуется первой строкой сценария ставить вызов:

error_reporting(E_ALL);

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

1.5 ОПЕРАТОР ОТКЛЮЧЕНИЯ ОШИБОК

Есть и еще один аргумент в пользу того, чтобы всегда включать полный контроль ошибок. Это — существование в РНР оператора @. Если этот оператор поставить перед любым выражением, то все ошибки, которые там возникнут, будут проигнорированы.

Если в выражении используется результат работы функции, из которой вызывается другая функция и т. д., то предупреждения будут заблокированы для каждой из них. Поэтому осторожно применяйте @.

Например:

if (!@filemtime("notextst.txt") )

echo "Файл не существует!";

Попробуйте убрать оператор @ — тут же получите сообщение: "Файл не найден", а только после этого — вывод оператора echo. Однако с оператором @ предупреждение будет подавлено, что и требовалось.

В приведенном примере, возможно, несколько логичнее было бы воспользоваться функцией file_exists(), которая как раз и предназначена для определения факта существования файла, но в некоторых ситуациях это не подойдет. Например:

//Обновить файл, если он не существует или очень старый

if ( ! file_exists($fname) | | filemtime ($fname) <time () -60*60)

myFunctionForUpdateFile($fname);

Сравните со следующим фрагментом:

// Обновить файл, если он не существует или очень старый

if (@filemtime($fname)<time()-60*60)

myFunctionForUpdateFile($fname);

Всегда помните об операторе @. Он удобен. Рекомендуется не рисковать, задавая слабый контроль ошибок при помощи функции error_reporting(), если такой контроль и так можно локально установить при помощи оператора @?

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

Листинг 1.1. Файл er.php

<?php ## Отключение ошибок: логи не модифицируются.

error_reporting(E_ALL);

ini_set("error_log", "log.txt");

ini_set("log_errors", true);

@filemtime("spoon");

?>

Запустив приведенный скрипт, вы заметите, что файл журнала log.txt даже не создался. Попробуйте теперь убрать оператор @ — вы- получите предупреждение "stat failed for spoon", и оно же запишется в log.txt.

1.5.1 ПРИМЕР ИСПОЛЬЗОВАНИЯ ОПЕРАТОРА @

Пусть имеется форма с submit-кнопкой, и нужно в сценарии определить, нажата ли она. Можно сделать это так:

<?php

if (!empty($submit)) echo "Кнопка нажата!";

…

?>

Согласитесь, код листинга 1.2 элегантнее.

Листинг 1.2. Файл submit.php

<?php ## Удобство оператора @.

if (@$_REQUEST['submit']) echo "Кнопка нажата!"

?>

<form action="<?=$_SERVER['SCRIPT_NAME']?>">

<input type="submit" name="submit" value="Go!">

</form>

1.5.2 ПРЕДОСТЕРИЖЕНИЯ ПО ПРИМЕНЕНИЮ ОПЕРАТОРА ОТКЛЮЧЕНИЯ ОШИБОК @

Оператор @ следует применять с осторожностью. Например, следующий код никуда не годится — постарайтесь не повторять его в своих программах.

// Не подавляйте сообщения об ошибках во включаемых файлах — иначе

// отладка превратится в кромешный ад!

@include "mistake.php";

//Не используйте оператор @ перед функциями, написанными на РНР,

// если только нет 100%-й уверенности в том, что они работают

// корректно в любой ситуации!

@myOwnBigFunction() ;

Рекомендации, в каких случаях применение оператора подавления ошибок оправдано и относительно безопасно:

● в конструкциях if (@$_REQUEST[' key' ]) для проверки существования (и ненулевого значения) элемента массива;

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