Оператор управления ошибками.
- print , echo и другие функции, производящие вывод
- Необработанные разделы, предшествующие
Если источник ошибки упоминается как за закрытие?> то здесь выписывается какой-то пропущенный или необработанный текст. Маркер конца PHP не завершает выполнение script при этом точка. Любые символы текста/пробела после того, как они будут выписаны как содержимое страницы до сих пор.
Общепринято, в частности, новичкам, что trailing ?> PHP теги close должны быть опущены. Это предотвращает небольшую часть этих случаев. (Чаще всего сценарии include()d являются виновниками.)
- Источник ошибки, указанный как "Неизвестно в строке 0"
Обычно это расширение PHP или php.ini, если источник ошибок конкретизируется.
- Иногда параметр настройки потока gzip или ob_gzhandler .
- Но это может быть и любой загруженный в два раза модуль extension= генерирование неявного сообщения о запуске/предупреждении PHP.
- Предыдущие сообщения об ошибках
Если другой оператор или выражение PHP вызывает предупреждение или уведомление распечатывается, что также считается преждевременным выходом.
В этом случае вам нужно избежать ошибки, задержать выполнение оператора или подавить сообщение, например. isset() или @() - когда либо не препятствует отладке позже.
- Значения байтов байтов в начале php файла. Изучите ваши php файлы с помощью шестнадцатеричного редактора, чтобы узнать, является ли этот случай. Они должны начинаться с байтов 3F 3C . Вы можете безопасно удалить спецификацию EF BB BF с начала файлов.
- Явный вывод, например вызовы echo , printf , readfile , passthru , код до
DO CHECK FOR BLANK SPACES HERE AS WELL; THIS LINE (blank line) SHOULD NOT EXIST.
Большая часть времени это должно решить ваш problem.Do проверить все файлы, связанные с файлом вам require .
Примечание. Иногда EDITOR (IDE), например gedit (стандартный Linux-редактор), добавляет одну пустую строку в файл save save. Этого не должно быть. Если вы используете linux. вы можете использовать редактор VI для удаления пробела/строк после?> в конце страницы.
Если это не ваше дело, тогда вы можете использовать ob_start для буферизации вывода, как показано ниже:
Возможное решение 2:
Это приведет к буферизации вывода, и ваши заголовки будут созданы после буферизации страницы.
Вместо строки ниже
//header("Location:".ADMIN_URL."/index.php");
написать
Echo("location.href = "".ADMIN_URL."/index.php?msg=$msg";");
?>
Параметр функции может быть комбинацией следующих констант
Константа Описание E_ERROR Критические ошибки, прерывающие выполнение скрипта (например, ошибка выделения памяти) E_WARNING Предупреждения E_PARSE Синтаксические ошибки исходного кода E_NOTICE Замечания E_CORE_ERROR Критические ошибки, возникающие на этапе запуска исполнения скрипта E_CORE_WARNING Предупреждения, возникающие на этапе запуска E_COMPILE_ERROR Ошибки компиляции E_COMPILE_WARNING Предупреждения компиляции E_USER_ERROR Пользовательские ошибки, созданные с помощью функции trigger_error() E_USER_WARNING Пользовательские предупреждения, созданные с помощью функции trigger_error() E_USER_NOTICE Пользовательские замечания, созданные с помощью функции trigger_error() E_ALL Все возможные ошибки, предупреждения и замечания E_STRICT Замечания времени выполнения E_RECOVERABLE_ERROR Критические ошибки, допускающие дальнейшее исполнение кода. Например:
Иногда возникают случаи, когда надо запретить вывод ошибок не для всего скрипта, а лишь для его части. В этом случае необходимо пользоваться оператором подавления ошибок "@" (собака). Будучи поставлен перед выражением, этот оператор запрещает вывод на зкран всех сообщений, предупреждений или замечаний, генерируемых выражением. Например:
Пользовательские ошибки могут быть без проблем перехвачены и обработаны, причем обработка ошибок построена таким образом, что может выполняться без завершения основного скрипта.
Для генерации ошибки служит функция trigger_error() , которой передаётся два параметра - тип ошибки и собственно её текст. Тип ошибки определяется стандартными константами, рассмотренными выше.
Например:
Вызов функции trigger_error не приводит к аварийному завершению скрипта, а значит весь последующий код будет нормально исполняться. Если же прервать выполнение всё-таки необходимо, то программист должен сделать это "вручную", используя средства языка.
Как и для исключений, для ошибок можно установить собственный обработчик. Делается это при помощи функции set_error_handler() , которой передаётся имя функции-обработчика и список типов ошибок, для которых эта функция вызывается. Функция имеет четыре параметра: номер ошибки, текст ошибки, имя файла и номер строки, где ошибка произошла. Например:
Если функция обработки ошибки возвращает true, то внутренний обработчик PHP не вызывается, а если false - то после выхода из пользовательской процедуры ошибка будут передана в стандартный внутренний обработчик. Это позволяет программисту реагировать только на часть возникающих ошибок, отдавая остальное старндартным обработчикам PHP.
Восстановить предыдущий обработчик можно, вызвав функцию restore_error_handler():
Таким способом можно включать и выключать обработчики ошибок по мере необходимости. Но злоупотреблять такими операциями не стоит - слишком высока вероятность запутаться и перепутать обработчики. В большинстве случаев достаточно одного, но хорошо написанного обработчика, который пишет ошибки в лог-файл или базу данных, пересылает их на email администратора и делает другие полезные операции.
Обработка ошибок - один из важнейших элементов написания скриптов. Некачественно написанный срипт может стать не только головной болью веб-мастера или администратора сайта. "Бажный" (от слова "баг" - ошибка) скрипт представляет серьёзную угрозу безопасности. В руках умелого взломщика текст ошибки превращается в отмычку, открывающую доступ ко всему содержимому сайта, а может быть и сервера.
PHP поддерживает один оператор управления ошибками: знак @. В случае, если он предшествует какому-либо выражению в PHP-коде, любые сообщения об ошибках, генерируемые этим выражением, будут проигнорированы.
Если вы установили собственную функцию обработки ошибок с помощью set_error_handler() , то она все равно будет вызвана, однако, если внутри этой функции будет вызвана функция error_reporting() , то она вернет 0, если функция, вызвавшая данную ошибку, была подавлена с помощью @.
В случае, если установлена опция track_errors , все генерируемые сообщения об ошибках будут сохраняться в переменной $php_errormsg . Эта переменная будет перезаписываться при каждой новой ошибке, поэтому в случае необходимости проверяйте ее сразу же.
Замечание : Оператор @ работает только с выражениями . Есть простое правило: если что-то возвращает значение, значит вы можете использовать перед ним оператор @. Например, вы можете использовать @ перед именем переменной, произвольной функцией или вызовом include , константой и так далее. В то же время вы не можете использовать этот оператор перед определением функции или класса, условными конструкциями, такими как if , foreach и т.д.
Также ознакомьтесь с описанием функции error_reporting() и разделом руководства Обработка ошибок и функции логирования .
Внимание
На сегодняшний день оператор "@" подавляет вывод сообщений даже о критических ошибках, прерывающих работу скрипта. Помимо всего прочего, это означает, что если вы использовали "@" для подавления ошибок, возникающих при работе какой-либо функции, в случае если она недоступна или написана неправильно, дальнейшая работа скрипта будет остановлена без каких-либо уведомлений.
12 years ago
To suppress errors for a new class/object:
I found this most useful when connecting to a
database, where i wanted to control the errors
and warnings displayed to the client, while still
using the class style of access.14 years ago
Better use the function trigger_error() ()
to display defined notices, warnings and errors than check the error level your self. this lets you write messages to logfiles if defined in the php.ini, output
messages in dependency to the error_reporting() level and suppress output using the @-sign.8 years ago
If you use the ErrorException exception to have a unified error management, I"ll advise you to test against error_reporting in the error handler, not in the exception handler as you might encounter some headaches like blank pages as error_reporting might not be transmitted to exception handler.
{
}function catchException ($e )
{
{
return;
}// Do some stuff
}?>
It would be better to do:Function exception_error_handler ($errno , $errstr , $errfile , $errline )
{
if (error_reporting () === 0 )
{
return;
}Throw new ErrorException ($errstr , 0 , $errno , $errfile , $errline );
}Set_error_handler ("exception_error_handler" );
function catchException ($e )
{
// Do some stuff
}Set_exception_handler ("catchException" );
?>
4 years ago
While you should definitely not be too liberal with the @ operator, I also disagree with people who claim it"s the ultimate sin.
For example, a very reasonable use is to suppress the notice-level error generated by parse_ini_file() if you know the .ini file may be missing.
In my case getting the FALSE return value was enough to handle that situation, but I didn"t want notice errors being output by my API.TL;DR: Use it, but only if you know what you"re suppressing and why.
2 years ago
What is PHP"s behavior for a variable that is assigned the return value of an expression protected by the Error Control Operator when the expression encounteres an error?
Based on the following code, the result is NULL (but it would be nice if this were confirmed to be true in all cases).
$var = 3 ;
$arr = array();$var = @ $arr [ "x" ]; // what is the value of $var after this assignment?
// is it its previous value (3) as if the assignment never took place?
// is it FALSE or NULL?
// is it some kind of exception or error message or error number?Var_dump ($var ); // prints "NULL"
?>
5 years ago
I was wondering if anyone (else) might find a directive to disable/enable to error operator would be a useful addition. That is, instead of something like (which I have seen for a few places in some code):
If (defined (PRODUCTION )) {
@function();
}
else {
function();
}?>
There could be something like this:If (defined (PRODUCTION )) {
ini_set ("error.silent" , TRUE );
}
else {
ini_set ("error.silent" , FALSE );
}?>
12 years ago
If you want to log all the error messages for a php script from a session you can use something like this:
Hope this helps someone...
В скрипте PHP1) В PHP есть всего лишь один оператор, который поддерживает систему управления ошибками - это знак @ . Он позволяет проигнорировать сообщение любое сообщение об ошибке. Его нужно ставить ПЕРЕД выражением, которое может её содержать.
Часто слышал о такой проблеме от других пользователей. Одним из-за хостера нужно скрыть появляющиеся ошибки, другим наоборот - понять, что происходит с их кодом, потому что ни одна ошибка не показывается. В этой статье постараюсь показать все основные способы отобразить / скрыть ошибки.В примере специально допущена ошибка, но она НЕ будет отображена
$value = @$var[$key];
2) Также можно перед проверяемым скриптом PHP можно вставить настройку параметра отображения ошибок (display_errors ). Он может приобретать значение либо On (показывать), либо Off (скрыть).Ini_set("display_errors","On");
error_reporting("E_ALL");
И соответственно после кода, который проверялся на ошибки, выставить параметр обратно.Ini_set("display_errors","Off");
Например, Вы хотите увидеть ошибки в скрипте
Ini_set("display_errors", "On"); // сообщения с ошибками будут показываться
В файле.htaccess Чаще всего проблему решают именно указанием настроек в файле .htaccess , который располагается в корневой директории сайта. В строке php_flag display_errors нужно также выставить On или Off
error_reporting(E_ALL); // E_ALL - отображаем ВСЕ ошибки
$value = $var[$key]; // пример ошибки
ini_set("display_errors", "Off"); // теперь сообщений НЕ будет
Можно выставить наоборот (в верхнем off, а в нижнем on), чтобы в конкретном отрезке кода ошибки НЕ отображались.Php_flag display_errors On
В файле php.ini Как видите, параметр можно указать в нескольких местах. Однако, если у Вы хотите, чтобы целиком на сайте этот параметр имел определённое значение, то проще выставить его в файле php.ini.(к нему на хостинге не всегда может быть доступ), но в этом случае можно будет даже обойти настройки всего хостинга
#показать все ошибки кроме предупреждений (Notice)
php_value error_reporting "E_ALL & ~E_NOTICE"В php.ini :
Error_reporting = E_ALL
display_errors On
В верхней строке выбираем все виды ошибок, в нижней даём добро на их отображение.После правок необходимо перезапустить Apache, чтобы настройки были изменены и вступили в силу (graceful или restart):
Sudo apachectl -k graceful
В каком порядке обрабатывается параметр ошибок В самом начале учитывается параметр php.ini , затем.htaccess , а после то, что указано непосредственно в скрипте PHP. Так что если что-то не сработало, то смотрим по цепочку выше, возможно, там настройка другая.Как обычно спасибо за внимание и удачи! Надеюсь статья была полезна!
Преднамеренное:
Если у вас error_reporting или display_errors отключено на php.ini , то предупреждение не появится. Но игнорирование ошибок не вызовет проблемы далеко. Заголовки по-прежнему не могут быть отправлены после преждевременного выхода.
Поэтому, когда header("Location: ...") перенаправляет молча, рекомендуется проконтролировать предупреждения. Обозначить их двумя простыми командами на вызов script:
Error_reporting(E_ALL); ini_set("display_errors", 1);
Или set_error_handler("var_dump"); , если все остальное не работает.
Говоря о переадресации заголовков, вы должны часто использовать идиому вроде это для конечных путей кода:
Exit(header("Location: /finished.html"));
Предпочтительно даже функция полезности, которая печатает сообщение пользователя в случае сбоев header() .
Буферизация вывода в качестве обходного путиОн может скрывать пробелы для вывода HTML. Но как только приложение логические попытки отправить двоичный контент (например, сгенерированное изображение), буферизованный посторонний выход становится проблемой. (Необходимость ob_clean() как предыдущий вариант.)
Буфер ограничен по размеру и может быть легко переполнен, если оставить его по умолчанию. И это не редкость, трудно отследить когда это произойдет.
Оба подхода могут стать ненадежными - в частности, при переключении между разработки и/или производственные серверы. Именно поэтому буферизация вывода широко считается просто костылем/строго обходным путем.
Это сообщение об ошибке запускается, когда что-либо отправляется перед отправкой заголовков HTTP (с setcookie или header). Общие причины вывода чего-либо перед заголовками HTTP:
Случайные пробелы, часто в начале или в конце файлов, например:
Чтобы избежать этого, просто оставьте закрытие?>
