Php вывести код ошибки

Как включить или выключить отображение ошибок в PHP?

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

В скрипте PHP

1) В PHP есть всего лишь один оператор, который поддерживает систему управления ошибками — это знак @. Он позволяет проигнорировать сообщение любое сообщение об ошибке. Его нужно ставить ПЕРЕД выражением, которое может её содержать.

В примере специально допущена ошибка, но она НЕ будет отображена

2) Также можно перед проверяемым скриптом PHP можно вставить настройку параметра отображения ошибок (display_errors). Он может приобретать значение либо On (показывать), либо Off (скрыть).

И соответственно после кода, который проверялся на ошибки, выставить параметр обратно.

Например, Вы хотите увидеть ошибки в скрипте

Можно выставить наоборот (в верхнем off, а в нижнем on), чтобы в конкретном отрезке кода ошибки НЕ отображались.

В файле .htaccess

Чаще всего проблему решают именно указанием настроек в файле .htaccess, который располагается в корневой директории сайта. В строке php_flag display_errors нужно также выставить On или Off

Если Вам нужно работать с конкретным типом ошибок, то привожу основные их виды:

E_ALL — все ошибки
E_ERROR — ошибки функций (критические)
E_WARNING — предупреждения
E_PARSE — ошибки синтаксиса
E_NOTICE — замечания (ненормальный код — кодировка и тп)
E_CORE_ERROR — ошибка обработчика
E_CORE_WARNING — предупреждения обработчика
E_COMPILE_ERROR — ошибка компилятора
E_COMPILE_WARNING — предупреждение компилятора
E_USER_ERROR — ошибка пользователей
E_USER_WARNING — предупреждение пользователей
E_USER_NOTICE — уведомления пользователей

В файле php.ini

Как видите, параметр можно указать в нескольких местах. Однако, если у Вы хотите, чтобы целиком на сайте этот параметр имел определённое значение, то проще выставить его в файле php.ini.(к нему на хостинге не всегда может быть доступ), но в этом случае можно будет даже обойти настройки всего хостинга

В php.ini:

В верхней строке выбираем все виды ошибок, в нижней даём добро на их отображение.

После правок необходимо перезапустить Apache, чтобы настройки были изменены и вступили в силу (graceful или restart):

В каком порядке обрабатывается параметр ошибок

В самом начале учитывается параметр php.ini , затем .htaccess , а после то, что указано непосредственно в скрипте PHP. Так что если что-то не сработало, то смотрим по цепочку выше, возможно, там настройка другая.

Как обычно спасибо за внимание и удачи! Надеюсь статья была полезна!

Источник

Как настроить отображение ошибок в PHP

В этом руководстве мы расскажем о различных способах того, как в PHP включить вывод ошибок. Мы также обсудим, как записывать ошибки в журнал (лог).

Как быстро показать все ошибки PHP

Самый быстрый способ отобразить все ошибки и предупреждения php — добавить эти строки в файл PHP:

Что именно делают эти строки?

Функция ini_set попытается переопределить конфигурацию, найденную в вашем ini-файле PHP.

Displayerrors и displaystartuperrors — это только две из доступных директив. Директива displayerrors определяет, будут ли ошибки отображаться для пользователя. Обычно директива dispay_errors не должна использоваться для «боевого» режима работы сайта, а должна использоваться только для разработки.

displaystartuperrors — это отдельная директива, потому что displayerrors не обрабатывает ошибки, которые будут встречаться во время запуска PHP. Список директив, которые могут быть переопределены функцией iniset, находится в официальной документации .

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

Отображение ошибок PHP через настройки в php.ini

Если ошибки в браузере по-прежнему не отображаются, то добавьте директиву:

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

Актуальный INI-файл можно найти в выводе функции phpinfo (). Он помечен как «загруженный файл конфигурации» («loaded configuration file»).

Отображать ошибки PHP через настройки в .htaccess

Включить или выключить отображение ошибок можно и с помощью файла .htaccess, расположенного в каталоге сайта.

.htaccess также имеет директивы для displaystartuperrors и display_errors.

Вы можете настроить displayerrors в .htaccess или в вашем файле PHP.ini. Однако многие хостинг-провайдеры не разрешают вам изменять ваш файл PHP.ini для включения displayerrors.

В файле .htaccess также можно включить настраиваемый журнал ошибок, если папка журнала или файл журнала доступны для записи. Файл журнала может быть относительным путем к месту расположения .htaccess или абсолютным путем, например /var/www/html/website/public/logs .

Включить подробные предупреждения и уведомления

Иногда предупреждения приводят к некоторым фатальным ошибкам в определенных условиях. Скрыть ошибки, но отображать только предупреждающие (warning) сообщения можно вот так:

Для отображения предупреждений и уведомлений укажите «EWARNING | ENOTICE».

Также можно указать EERROR, EWARNING, EPARSE и ENOTICE в качестве аргументов. Чтобы сообщить обо всех ошибках, кроме уведомлений, укажите «EALL &

ENOTICE», где EALL обозначает все возможные параметры функции errorreporting.

Более подробно о функции error_reporting ()

Функция сообщения об ошибках — это встроенная функция PHP, которая позволяет разработчикам контролировать, какие ошибки будут отображаться. Помните, что в PHP ini есть директива error_reporting, которая будет задана ​​этой функцией во время выполнения.

Для удаления всех ошибок, предупреждений, сообщений и уведомлений передайте в функцию error_reporting ноль. Можно сразу отключить сообщения отчетов в ini-файле PHP или в .htaccess:

PHP позволяет использовать переменные, даже если они не объявлены. Это не стандартная практика, поскольку необъявленные переменные будут вызывать проблемы для приложения, если они используются в циклах и условиях.

Иногда это также происходит потому, что объявленная переменная имеет другое написание, чем переменная, используемая для условий или циклов. Когда ENOTICE передается в функцию errorreporting, эти необъявленные переменные будут отображаться.

Функция сообщения об ошибках позволяет вам фильтровать, какие ошибки могут отображаться. Символ «

» означает «нет», поэтому параметр

E_NOTICE означает не показывать уведомления. Обратите внимание на символы «&» и «|» между возможными параметрами. Символ «&» означает «верно для всех», в то время как символ «|» представляет любой из них, если он истинен. Эти два символа имеют одинаковое значение в условиях PHP OR и AND.

Эти три строки кода делают одно и то же, они будут отображать все ошибки PHP. Errorreporting(EALL) наиболее широко используется разработчиками для отображения ошибок, потому что он более читабелен и понятен.

Включить ошибки php в файл с помощью функции error_log ()

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

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

Параметр type, если он не определен, будет по умолчанию равен 0, что означает, что эта информация журнала будет добавлена ​​к любому файлу журнала, определенному на веб-сервере.

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

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

Журнал ошибок PHP через конфигурацию веб-сервера

Лучший способ регистрировать ошибки — это определить их в файле конфигурации веб-сервера.

Однако в этом случае вам нужно попросить администратора сервера добавить следующие строки в конфигурацию.

Пример для Apache:

В nginx директива называется error_log.

Теперь вы знаете, как в PHP включить отображение ошибок. Надеемся, что эта информация была вам полезна.

Источник

Функции обработки ошибок

Смотрите также функцию syslog() .

Содержание

• debug_backtrace — Выводит стек вызовов функций в массив
• debug_print_backtrace — Выводит стек вызовов функций
• error_clear_last — Очистить самую последнюю ошибку
• error_get_last — Получение информации о последней произошедшей ошибке
• error_log — Отправляет сообщение об ошибке заданному обработчику ошибок
• error_reporting — Задаёт, какие ошибки PHP попадут в отчёт
• restore_error_handler — Восстанавливает предыдущий обработчик ошибок
• restore_exception_handler — Восстанавливает предыдущий обработчик исключений
• set_error_handler — Задаёт пользовательский обработчик ошибок
• set_exception_handler — Задаёт пользовательский обработчик исключений
• trigger_error — Вызывает пользовательскую ошибку/предупреждение/уведомление
• user_error — Псевдоним trigger_error

User Contributed Notes 9 notes

PHP5 only (only tested with php5.0).

If you, for some reason, prefer exceptions over errors and have your custom error handler (set_error_handler) wrap the error into an exception you have to be careful with your script.

Because if you, instead of just calling the exception handler, throws the exception, and having a custom exception handler (set_exception_handler). And an error is being triggered inside that exception handler, you will get a weird error:
«Fatal error: Exception thrown without a stack frame in Unknown on line 0»

This error is not particulary informative, is it? 🙂

This example below will cause this error.
class PHPErrorException extends Exception
<
private $context = null ;
public function __construct
( $code , $message , $file , $line , $context = null )
<
parent :: __construct ( $message , $code );
$this -> file = $file ;
$this -> line = $line ;
$this -> context = $context ;
>
>;

function error_handler ( $code , $message , $file , $line ) <
throw new PHPErrorException ( $code , $message , $file , $line );
>

function exception_handler ( Exception $e )
<
$errors = array(
E_USER_ERROR => «User Error» ,
E_USER_WARNING => «User Warning» ,
E_USER_NOTICE => «User Notice» ,
);

echo $errors [ $e -> getCode ()]. ‘: ‘ . $e -> getMessage (). ‘ in ‘ . $e -> getFile ().
‘ on line ‘ . $e -> getLine (). «\n» ;
echo $e -> getTraceAsString ();
>

set_error_handler ( ‘error_handler’ );
set_exception_handler ( ‘exception_handler’ );

// Throw exception with an /unkown/ error code.
throw new Exception ( ‘foo’ , 0 );
?>

There are however, easy fix for this as it’s only cause is sloppy code.
Like one, directly call exception_handler from error_handler instead of throwing an exception. Not only does it remedy this problem, but it’s also faster. Though this will cause a `regular` unhandled exception being printed and if only «designed» error messages are intended, this is not the ultimate solution.

So, what is there to do? Make sure the code in exception_handlers doesn’t cause any errors! In this case a simple isset() would have solved it.

Although the root user writes to the files ‘error_log’ and ‘access_log’, the Apache user has to own the file referenced by ‘error_log = filename’ or no log entries will be written.

; From php.ini
; Log errors to specified file.
error_log = /usr/local/apache/logs/php.errors

[root@www logs]$ ls -l /usr/local/apache/logs/php.errors
-rw-r—r— 1 nobody root 27K Jan 27 16:58 php.errors

I keep seeing qualification lists for error types/error-nums as arrays; In user notes and in the manual itself. For example, in this manual entry’s example, when trying to seperate behavior for the variable trace in the error report:

// set of errors for which a var trace will be saved
$user_errors = array( E_USER_ERROR , E_USER_WARNING , E_USER_NOTICE );

if ( in_array ( $errno , $user_errors )) <
//. whatever
>

//. ?>

I was under the impression that PHP error code values where bitwise flag values. Wouldn’t bitwise masking be better? So I propose a slightly better way:
//.

$user_errors = E_USER_ERROR | E_USER_WARNING | E_USER_NOTICE ;

if ( $errno & $user_errors ) <
//. whatever
>

//. ?>
Or for those of you who don’t like the idea of using an integer as the condition in an if statement:

if (( $errno & $user_errors ) > 0 ) <
//. whatever
>
?>

I think that’s much more efficient than using _yet another_ array() constuct and an in_array().

If I am wrong, and the E_* constants aren’t supposed to be used in this fashion (ie, the constans aren’t guaranteed to be bitwise, which would be odd since that’s how they’re setup in the php.ini file), then delete me. I just don’t see why one should be using arrays when bitwise comparisons will work, considering the bitwise method should be MUCH more efficient.

It is totally possible to use debug_backtrace() inside an error handling function. Here, take a look:

function errorHandler ( $errno , $errstr , $errfile , $errline , $errcontext )
<
echo ‘Into ‘ . __FUNCTION__ . ‘() at line ‘ . __LINE__ .
«\n\n—ERRNO—\n» . print_r ( $errno , true ).
«\n\n—ERRSTR—\n» . print_r ( $errstr , true ).
«\n\n—ERRFILE—\n» . print_r ( $errfile , true ).
«\n\n—ERRLINE—\n» . print_r ( $errline , true ).
«\n\n—ERRCONTEXT—\n» . print_r ( $errcontext , true ).
«\n\nBacktrace of errorHandler()\n» .
print_r ( debug_backtrace (), true );
>

function a ( )
<
//echo «a()’s backtrace\n».print_r( debug_backtrace(), true);
asdfasdf ; // oops
>

function b ()
<
//echo «b()’s backtrace\n».print_r( debug_backtrace(), true);
a ();
>

Into errorhandler() at line 9

—ERRSTR—
Use of undefined constant asdfasdf — assumed ‘asdfasdf’

Backtrace of errorHandler()
Array
(
[0] => Array
(
[function] => errorhandler
[args] => Array
(
[0] => 8
[1] => Use of undefined constant asdfasdf — assumed ‘asdfasdf’
[2] => /home/theotek/test-1.php
[3] => 23
[4] => Array
(
)

[1] => Array
(
[file] => /home/theotek/test-1.php
[line] => 23
[function] => a
)

[2] => Array
(
[file] => /home/theotek/test-1.php
[line] => 30
[function] => a
[args] => Array
(
)

[3] => Array
(
[file] => /home/theotek/test-1.php
[line] => 33
[function] => b
[args] => Array
(
)

So, the first member of the backtrace’s array is not really surprising, except from the missing «file» and «line» members.

The second member of the backtrace seem the be a hook inside the zend engine that is used to trigger the error.

Other members are the normal backtrace.

If you are using PHP as an Apache module, your default behavior may be to write PHP error messages to Apache’s error log. This is because the error_log .ini directive may be set equal to «error_log» which is also the name of Apache’s error log. I think this is intentional.

However, you can separate Apache errors from PHP errors if you wish by simply setting a different value for error_log. I write mine in the /var/log folder.

When configuring your error log file in php.ini, you can use an absolute path or a relative path. A relative path will be resolved based on the location of the generating script, and you’ll get a log file in each directory you have scripts in. If you want all your error messages to go to the same file, use an absolute path to the file.

In some application development methodologies, there is the concept of an application root directory, indicated by «/» (even on Windows). However, PHP does not seem to have this concept, and using a «/» as the initial character in a log file path produces weird behavior on Windows.

If you are running on Windows and have set, in php.ini:

You will get some, but not all, error messages. The file will appear at

and contain internally generated error messages, making it appear that error logging is working. However, log messages requested by error_log() do NOT appear here, or anywhere else, making it appear that the code containing them did not get processed.

Apparently on Windows the internally generated errors will interpret «/» as «C:\» (or possibly a different drive if you have Windows installed elsewhere — I haven’t tested this). However, the error_log process apparently can’t find «/» — understandably enough — and the message is dropped silently.

I have found that on servers that enforce display_errors to be off it is very inconvenient to debug syntax errors since they cause fatal startup errors. I have used the following method to bypass this limitation:

The syntax error is inside the file «syntax.php», therefore I create a file «syntax.debug.php» with the following code:

( E_ALL );
ini_set ( ‘display_errors’ , ‘On’ );

Источник