php show php error
How to show errors and warnings in PHP
In this article, I am going to explain you about how to show errors in php.
By using below code we will display errors in php
In php.ini by set display_errors as on by using below code.
Types of Errors in PHP
There are four basic types of runtime errors in PHP:
3. Warnings:
Warnings are more severe errors like attempting to include() a file which does not exist. By default, these errors are displayed to the user, but they do not result in script termination.
4.Parse Error :
it’s syntax error or missing code error.
it will stop script execution.
Examples for Warnings and Fatal error:
Warnings in PHP are represented by E_WARNING. When these error occur execution of the script is not halted. For example,
by using include function added one php file but forgot to create this file in this root directoy we will get warnings.
Fatal error are represented by E_ERROR. By using require function added one php file but forgot include that file we got fatal error.
Simple example for warnings:
But i forgot include dept.php
i got below warning i got output.
see the below image for this example.
Simple for Fatal errors
my sample php code as shown bleow
But i forgot include dept.php in my code.
i got fatal error like this.
if you got fatal error our code terminated.So take care of this type of errors.
Here the functions include and require include one file into another file.
Difference between require, require_once, include and include_once
All these functions require, require_once, include and include_once are used to include the files in the php page but there is the slight difference between these functions.
Difference between require, require_once, include, include_once
Difference between require and include is that if the file you want to include is not found then include function give you a warning and executes the remaining code in of php page where you write the include function. While require gives you fatal error if the file you want to include is not found and the remaining code of the php page will not execute.
Example for include function:
By using this function we can include dept.php file in our php file.
Example for inclide_once function:
here include and include_once functions are same.but dept.php file included in our file multiple time it will include only one time.
Example for require function:
it is like include function.But the only difference is it returns the fatal error if included file missed as include function returns warnings.
Example for require_once function:
it is same as include_once funcitons.
Out of all require_once is best.
Then based on your requirement you can choose which you want to show :
For All Error, Warning and Notice
For All Errors
For All Warnings
For All Notice
By Using htaccess we will display errors in php
PHP error_log() Function
By using this function Send error messages to the web server’s error log
Sample code for this
if we got DB connection error in our error_log.txt file that error tacked like «Failed to connect ot MY DataBase!» as shown in the above example
By using following actions we will get errors info
error_reporting
(PHP 4, PHP 5, PHP 7, PHP 8)
error_reporting — Задаёт, какие ошибки PHP попадут в отчёт
Описание
Функция error_reporting() задаёт значение директивы error_reporting во время выполнения. В PHP есть много уровней ошибок. Используя эту функцию, можно задать уровень ошибок времени выполнения скрипта, которые попадут в отчёт. Если необязательный аргумент error_level не задан, error_reporting() вернёт текущее значение уровня протоколирования ошибок.
Список параметров
Новое значение уровня error_reporting. Это может быть битовая маска или именованные константы. При использовании именованных констант нужно будет следить за совместимостью с новыми версиями PHP. В новых версиях могут добавиться новые уровни ошибок, увеличиться диапазон целочисленных типов. Все это может привести к нестабильной работе при использовании старых целочисленных обозначений уровней ошибок.
Доступные константы уровней ошибок и их описания приведены в разделе Предопределённые константы.
Возвращаемые значения
Возвращает старое значение уровня error_reporting либо текущее значение, если аргумент error_level не задан.
Список изменений
Примеры
Пример #1 Примеры использования error_reporting()
// Выключение протоколирования ошибок
error_reporting ( 0 );
// Включать в отчёт простые описания ошибок
error_reporting ( E_ERROR | E_WARNING | E_PARSE );
// Включать в отчёт E_NOTICE сообщения (добавятся сообщения о
// непроинициализированных переменных или ошибках в именах переменных)
error_reporting ( E_ERROR | E_WARNING | E_PARSE | E_NOTICE );
// Добавлять сообщения обо всех ошибках, кроме E_NOTICE
error_reporting ( E_ALL &
// Добавлять в отчёт все ошибки PHP
error_reporting ( E_ALL );
// Добавлять в отчёт все ошибки PHP
error_reporting (- 1 );
Примечания
Смотрите также
User Contributed Notes 27 notes
If you just see a blank page instead of an error reporting and you have no server access so you can’t edit php configuration files like php.ini try this:
— create a new file in which you include the faulty script:
now errors of your faulty script should be reported.
this works fine with me. hope it solves your problem as well!
Under PHP 8.0, error_reporting() does not return 0 when then the code uses a @ character.
The example of E_ALL ^ E_NOTICE is a ‘bit’ confusing for those of us not wholly conversant with bitwise operators.
If you wish to remove notices from the current level, whatever that unknown level might be, use &
(and not) will always turn off the bits specified by the right-hand parameter, whether or not they were on or off.
The error_reporting() function won’t be effective if your display_errors directive in php.ini is set to «Off», regardless of level reporting you set. I had to set
to keep no error reporting as default, but be able to change error reporting level in my scripts.
I’m using PHP 4.3.9 and Apache 2.0.
Some E_STRICT errors seem to be thrown during the page’s compilation process. This means they cannot be disabled by dynamically altering the error level at run time within that page.
The work-around for this was to rename the file and replace the original with a error_reporting() call and then a require() call.
Ex, rename index.php to index.inc.php, then re-create index.php as:
( E_STRICT | E_NOTICE ));
require( ‘index.inc.php’ );
?>
That allows you to alter the error reporting prior to the file being compiled.
I discovered this recently when I was given code from another development firm that triggered several E_STRICT errors and I wanted to disable E_STRICT on a per-page basis.
So if you want to keep a log of all the errors even after page reloads (for help in debugging, maybe), running the PHP development server can be useful.
E_NOTICE integer value is 6135
I had the problem that if there was an error, php would just give me a blank page. Any error at all forced a blank page instead of any output whatsoever, even though I made sure that I had error_reporting set to E_ALL, display_errors turned on, etc etc. But simply running the file in a different directory allowed it to show errors!
Turns out that the error_log file in the one directory was full (2.0 Gb). I erased the file and now errors are displayed normally. It might also help to turn error logging off.
this is to show all errors for code that may be run on different versions
for php 5 it shows E_ALL^E_STRICT and for other versions just E_ALL
if anyone sees any problems with it please correct this post
To expand upon the note by chris at ocproducts dot com. If you prepend @ to error_reporting(), the function will always return 0.
( E_ALL );
var_dump (
error_reporting (), // value of E_ALL,
@ error_reporting () // value is 0
);
?>
To enable error reporting for *ALL* error messages including every error level (including E_STRICT, E_NOTICE etc.), simply use:
see more information about php 5.3 deprecated errors
If you want to see all errors in your local environment, you can set your project URL like «foo.com.local» locally and put that in bootstrap file.
error_reporting() has no effect if you have defined your own error handler with set_error_handler()
[Editor’s Note: This is not quite accurate.
E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR and E_COMPILE_WARNING error levels will be handled as per the error_reporting settings.
All other levels of errors will be passed to the custom error handler defined by set_error_handler().
Zeev Suraski suggests that a simple way to use the defined levels of error reporting with your custom error handlers is to add the following line to the top of your error handling function:
Display All PHP Errors: Basic & Advanced Usage
A PHP application might produce many different levels of earning and errors during its execution. Being able to see these errors is essential for developers trying to troubleshoot a misbehaving application. However, developers often have trouble when trying to display errors from their PHP applications. Instead, their apps just fail silently.
If you are having problems with your PHP web application and need to display all the errors and warnings, you are in the right place. In this tutorial, we will explain all the different ways to enable PHP errors and warnings. We will also discuss how to write the errors to a log file and even collect them via the Retrace’s error tracking feature.
Quickly Show All PHP Errors
The quickest way to display all php errors and warnings is to add these lines to your PHP code file:
What Do These Lines of Code Do Exactly?
The ini_set function will try to override the configuration found in your PHP ini file.
The display_errors and display_startup_errors are just two of the directives that are available. The display_errors directive will determine if the errors will be displayed or hidden to the user. Usually, the dispay_errors directive should be turned off after development.
The display_startup_errors, however, is a separate directive because the display_errors doesn’t handle the errors that will be encountered during PHP’s startup sequence. The list of the directives that can be overridden by the ini_set function is found in the official documentation.
Unfortunately, these two directives won’t be able to display parse errors such as missing semicolons or missing curly braces. In this case, the PHP ini configuration must be modified.
Configure PHP.ini to Display All Errors
If adding some of the PHP code errors doesn’t show in the browser during testing, then the PHP ini configuration has some additional directives to handle this.
The display_errors directive must be set to “on” in the PHP ini file. This will display all the errors including syntax or parse errors that cannot be displayed by just calling the ini_set function in the PHP code. The PHP ini file can be found in the displayed output of phpinfo() function and is labeled loaded configuration file. This directive in the ini configuration must be set to off, if the web application is in production.
Enable Detailed Warnings and Notices
Sometimes, the warnings that seem not to affect the application at the start will cause some fatal errors in certain conditions. These warnings must be fixed because this means that the application won’t run normally under certain scenarios. In case these warnings cause a lot of errors, then it would be more practical to hide the errors and just show what the warning messages are.
For a developer, showing warnings and hiding errors is just as simple as adding a single line of code. To show warnings and notices, the parameter for the error reporting function will be “E_WARNING | E_NOTICE”. The error_reporting function can accept E_ERROR, E_WARNING, E_PARSE, and E_NOTICE parameters as bitwise operators. To report all errors except for notices, then the parameter is “E_ALL &
E_NOTICE” where E_ALL stands for all the possible parameters of the error_reporting function.
In-depth With the error_reporting() function
The error reporting function is a built-in PHP function that allows developers to control which and how many errors will be shown in the application. Remember, the PHP ini configuration has an error_reporting directive that will be set by this function during runtime.
PHP allows variables to be used even when not declared. This is not a standard practice because undeclared variables will cause issues for the application once it is used in loops and conditions. Sometimes, this also happens because the declared variable has a different spelling than the variable being used for conditions or loops. When E_NOTICE is passed in the error_reporting function, then these undeclared variables will be displayed in the web application.
The error reporting function allows you to filter which errors can be shown. The “
” character means “not” or “no” so the parameter
E_NOTICE means not to show notices. Notice the “&” and “|” characters in between the possible parameters. The “&” character is for “true for all”, while the “|” character represents either one as long as it is true. These two characters have the same meaning in PHP conditions OR and AND.
These three lines of codes do exactly the same thing, it will show all PHP errors. The error_reporting(E_ALL) is the most widely used among developers to show error messages because it is more readable and understandable.
Log PHP errors to a file using the error_log() function
During production, error messages must not be shown to the end users, but this information must still be recorded for tracing purposes. The best way to record these error messages on a production web application is to store it in log files.
One easy way to use log files is to use the error_log function, which accepts four parameters. The only required parameter is the first parameter, which contains the details about the error or what’s to be logged. The type, destination, and header are all optional parameters for this function.
The type parameter, if not defined, will be 0 by default, which means this log information will be appended to whatever log file is defined in the web server.
The type 1 parameter will email an error log specified in the third parameter. To make this feature work, the PHP ini must have a proper SMTP configuration to be able to send out emails. These SMTP ini directives include host, encryption type, username, password, and port. This kind of error reporting is advisable to logging or notifying errors that need to be fixed as soon as found.
To log messages in a separate file defined by the configuration of the web server, then type 3 must be used. The third parameter will serve as the location of the log file and must be writable by the web server. The location of the log file can be a relative path to where this code is called or an absolute path.
Log PHP Errors Through the Web Server Configuration
For Apache, these files must be added to the virtual host of the specific website or application, usually located inside the sites-available folder for Ubuntu or httpd-vhosts file in Windows.
For nginx, similar to Apache, the directive is just called error_log. For both Apache and nginx web servers, the log files must be writable by the web server. Luckily, upon installation, the folders for the log files of these two web servers are already writable.
Automatically Collect PHP Errors With Retrace APM
One of the great features of Retrace is its ability to automatically collect all unhandled errors in your PHP application. Our PHP extension will catch the exception and forward them automatically to Retrace.
With Retrace, all the errors are automatically logged and formatted so that it can be viewed easily. Retrace will not only show what errors have occurred but also analyzes where and what caused it. The time and number of occurrences are also shown in the logs so that it would be a lot easier to focus on which issue to prioritize.
PHP для начинающих. Обработка ошибок
Не совершает ошибок только тот, кто ничего не делает, и мы тому пример — сидим и трудимся не покладая рук, читаем Хабр 🙂
В этой статье я поведу свой рассказа об ошибках в PHP, и о том как их обуздать.
Ошибки
Разновидности в семействе ошибок
Перед тем как приручать ошибки, я бы рекомендовал изучить каждый вид и отдельно обратить внимание на самых ярких представителей.
Чтобы ни одна ошибка не ушла незамеченной потребуется включить отслеживание всех ошибок с помощью функции error_reporting(), а с помощью директивы display_errors включить их отображение:
Фатальные ошибки
Самый грозный вид ошибок — фатальные, они могут возникнуть как при компиляции, так и при работе парсера или PHP-скрипта, выполнение скрипта при этом прерывается.
E_PARSE
Это ошибка появляется, когда вы допускаете грубую ошибку синтаксиса и интерпретатор PHP не понимает, что вы от него хотите, например если не закрыли фигурную или круглую скобочку:
Или написали на непонятном языке:
Лишние скобочки тоже встречаются, и не так важно круглые либо фигурные:
Отмечу один важный момент — код файла, в котором вы допустили parse error не будет выполнен, следовательно, если вы попытаетесь включить отображение ошибок в том же файле, где возникла ошибка парсера то это не сработает:
E_ERROR
Это ошибка появляется, когда PHP понял что вы хотите, но сделать сие не получилось ввиду ряда причин. Эта ошибка так же прерывает выполнение скрипта, при этом код до появления ошибки сработает:
Не был найден подключаемый файл:
Было брошено исключение (что это за зверь, расскажу немного погодя), но не было обработано:
При попытке вызвать несуществующий метод класса:
Отсутствия свободной памяти (больше, чем прописано в директиве memory_limit) или ещё чего-нить подобного:
Очень часто встречается при чтении либо загрузки больших файлов, так что будьте внимательны с вопросом потребляемой памяти
Рекурсивный вызов функции. В данном примере он закончился на 256-ой итерации, ибо так прописано в настройках xdebug (да, данная ошибка может проявиться в таком виде только при включении xdebug расширения):
Не фатальные
Данный вид не прерывает выполнение скрипта, но именно их обычно находит тестировщик. Именно такие ошибки доставляют больше всего хлопот начинающим разработчикам.
E_WARNING
Бывает, если используешь неправильный тип аргументов при вызове функций:
Их очень много, и перечислять все не имеет смысла…
E_NOTICE
Это самые распространенные ошибки, мало того, есть любители отключать вывод ошибок и клепают их целыми днями. Возникают при целом ряде тривиальных ошибок.
Когда обращаются к неопределенной переменной:
Когда обращаются к несуществующему элементу массива:
Когда обращаются к несуществующей константе:
Когда не конвертируют типы данных:
Для избежания подобных ошибок — будьте внимательней, и если вам IDE подсказывает о чём-то — не игнорируйте её:
E_STRICT
Данный тип ошибок актуален для PHP версии 5.6, и практически все их выпилили из
7-ки. Почитать подробней можно в соответствующей RFC. Если кто знает где ещё остались данные ошибки, то напишите в комментариях
E_DEPRECATED
Так PHP будет ругаться, если вы используете устаревшие функции (т.е. те, что помечены как deprecated, и в следующем мажорном релизе их не будет):
В моём редакторе подобные функции будут зачёркнуты:
Пользовательские
Этот вид, которые «разводит» сам разработчик кода, я уже давно их не встречал, и не рекомендую вам ими злоупотреблять:
Теперь, когда вы познакомились с большинством видов и типов ошибок, пора озвучить небольшое пояснение по работе директивы display_errors :
Приручение
Для работы с ошибками в PHP существует 3 функции:
У вас не получится назначить более одной функции для обработки ошибок, хотя очень бы хотелось регистрировать для каждого типа ошибок свой обработчик, но нет — пишите один обработчик, и всю логику отображения для каждого типа описывайте уже непосредственно в нём
С обработчиком, который написан выше есть одна существенная проблема — он не ловит фатальные ошибки, и при таких ошибках вместо сайта пользователи увидят лишь пустую страницу, либо, что ещё хуже, сообщение об ошибке. Дабы не допустить подобного сценария следует воспользоваться функцией register_shutdown_function() и с её помощью зарегистрировать функцию, которая всегда будет выполняться по окончанию работы скрипта:
Данная функция будет срабатывать всегда!
Но вернёмся к ошибкам, для отслеживания появления в коде ошибки воспользуемся функцией error_get_last(), с её помощью можно получить информацию о последней выявленной ошибке, а поскольку фатальные ошибки прерывают выполнение кода, то они всегда будут выполнять роль «последних»:
Хотел обратить внимание, что данный код хоть ещё и встречается для обработки ошибок, и вы возможно вы даже с ним столкнётесь, но он потерял актуальность начиная с 7-ой версии PHP. Что пришло на замену я расскажу чуть погодя.
О прожорливости
Проведём простой тест, и выясним — сколько драгоценных ресурсов кушает самая тривиальная ошибка:
В результате запуска данного скрипта у меня получился вот такой результат:
Теперь добавим ошибку в цикле:
Результат ожидаемо хуже, и на порядок (даже на два порядка!):
Вывод однозначен — ошибки в коде приводят к лишней прожорливости скриптов — так что во время разработки и тестирования приложения включайте отображение всех ошибок!
Тестирование проводил на различных версиях PHP и везде разница в десятки раз, так что пусть это будет ещё одним поводом для исправления всех ошибок в коде
Где собака зарыта
В PHP есть спец символ «@» — оператор подавления ошибок, его используют дабы не писать обработку ошибок, а положится на корректное поведение PHP в случае чего:
Если вы в такой способ подавляете ошибки, то это уменьшает нагрузку на процессор в сравнении с тем, если вы их просто скрываете (см. сравнительный тест выше), но в любом случае, подавление ошибок это зло
Исключения
В эру PHP4 не было исключений (exceptions), всё было намного сложнее, и разработчики боролись с ошибками как могли, это было сражение не на жизнь, а на смерть… Окунуться в эту увлекательную историю противостояния можете в статье Исключительный код. Часть 1. Стоит ли её читать сейчас? Не могу дать однозначный ответ, лишь хочу заметить, что это поможет вам понять эволюцию языка, и раскроет всю прелесть исключений.
Исключения — исключительные событие в PHP, в отличии от ошибок не просто констатируют наличие проблемы, а требуют от программиста дополнительных действий по обработке каждого конкретного случая.
К примеру, скрипт должен сохранить какие-то данные в кеш файл, если что-то пошло не так (нет доступа на запись, нет места на диске), генерируется исключение соответствующего типа, а в обработчике исключений принимается решение — сохранить в другое место или сообщить пользователю о проблеме.
В каких случаях стоит применять исключения:
Соответственно ловить данные исключения будем примерно так:
В данном примере приведен очень простой сценарий обработки исключений, когда у нас любая исключительная ситуация обрабатывается на один манер. Но зачастую, различные исключения требуют различного подхода к обработке, и тогда следует использовать коды исключений и задать иерархию исключений в приложении:
Теперь, если использовать эти исключения то можно получить следующий код:
Важно помнить, что Exception — это прежде всего исключительное событие, иными словами исключение из правил. Не нужно использовать их для обработки очевидных ошибок, к примеру, для валидации введённых пользователем данных (хотя тут не всё так однозначно). При этом обработчик исключений должен быть написан в том месте, где он будет способен его обработать. К примеру, обработчик для исключений вызванных недоступностью файла для записи должен быть в методе, который отвечает за выбор файла или методе его вызывающем, для того что бы он имел возможность выбрать другой файл или другую директорию.
Чтобы избежать подобной ситуации следует использовать функцию set_exception_handler() и установить обработчик для исключений, которые брошены вне блока try-catch и не были обработаны. После вызова такого обработчика выполнение скрипта будет остановлено:
Ещё расскажу про конструкцию с использованием блока finally — этот блок будет выполнен вне зависимости от того, было выброшено исключение или нет:
Для понимания того, что это нам даёт приведу следующий пример использования блока finally :
Т.е. запомните — блок finally будет выполнен даже в том случае, если вы в блоке catch пробрасываете исключение выше (собственно именно так он и задумывался).
Для вводной статьи информации в самый раз, кто жаждет ещё подробностей, то вы их найдёте в статье Исключительный код 😉
PHP7 — всё не так, как было раньше
Так, вот вы сейчас всю информацию выше усвоили и теперь я буду грузить вас нововведениями в PHP7, т.е. я буду рассказывать о том, с чем вы будете сталкиваться работая над современным PHP проектом. Ранее я вам рассказывал и показывал на примерах какой костыль нужно соорудить, чтобы отлавливать критические ошибки, так вот — в PHP7 это решили исправить, но? как обычно? завязались на обратную совместимость кода, и получили хоть и универсальное решение, но оно далеко от идеала. А теперь по пунктам об изменениях:
Сложно? Теперь на примерах, возьмём те, что были выше и слегка модернизируем:
В результате ошибку поймаем и выведем:
И чуть-чуть деталей:
TypeError — для ошибок, когда тип аргументов функции не совпадает с передаваемым типом:
ArithmeticError — могут возникнуть при математических операциях, к примеру когда результат вычисления превышает лимит выделенный для целого числа:
AssertionError — редкий зверь, появляется когда условие заданное в assert() не выполняется:
При настройках production-серверов, директивы zend.assertions и assert.exception отключают, и это правильно
Полный список предопределённых исключений вы найдёте в официальном мануале, там же иерархия SPL исключений.
При написании данного раздела были использованы материалы из статьи Throwable Exceptions and Errors in PHP 7.
Единообразие
— Там ошибки, тут исключения, а можно это всё как-то до кучи сгрести?
Да запросто, у нас же есть set_error_handler() и никто нам не запретит внутри оного обработчика бросить исключение:
Но данный подход с PHP7 избыточен, со всем теперь справляется Throwable :
Отладка
Иногда, для отладки кода, нужно отследить что происходило с переменной или объектом на определённом этапе, для этих целей есть функция debug_backtrace() и debug_print_backtrace() которые вернут историю вызовов функций/методов в обратном порядке:
В результате выполнения функции debug_print_backtrace() будет выведен список вызовов приведших нас к данной точке:
Assert
Функция assert() поменяла своё поведение при переходе от версии 5.6 к 7.0, и ещё сильней всё поменялось в версии 7.2, так что внимательней читайте changelog’и PHP 😉
Первый случай — это когда вам надо написать TODO прямо в коде, да так, чтобы точно не забыть реализовать заданный функционал:
В результате выполнения данного кода получим E_WARNING :
PHP7 можно переключить в режим exception, и вместо ошибки будет всегда появляться исключение AssertionError :
При необходимости, можно выбрасывать произвольное исключение:
Второй вариант использования — это создание некоего подобия TDD, но помните — это лишь подобие. Хотя, если сильно постараться, то можно получить забавный результат, который поможет в тестировании вашего кода:
Третий вариант — некое подобие на контрактное программирование, когда вы описали правила использования своей библиотеки, но хотите точно убедится, что вас поняли правильно, и в случае чего сразу указать разработчику на ошибку (я вот даже не уверен, что правильно его понимаю, но пример кода вполне рабочий):
Если вас заинтересовали контракты, то специально для вас у меня есть ссылочка на фреймворк PhpDeal.
Никогда не используйте assert() для проверки входных параметров, ведь фактически assert() интерпретирует первый параметр (ведёт себя как eval() ), а это чревато PHP-инъекцией. И да, это правильное поведение, ведь если отключить assert’ы, то все передаваемые аргументы будут проигнорированы, а если делать как в примере выше, то код будет выполняться, а внутрь отключенного assert’a будет передан булевый результат выполнения. А, и это поменяли в PHP 7.2 🙂
Если у вас есть живой опыт использования assert() — поделитесь со мной, буду благодарен. И да, вот вам ещё занимательно чтива по этой теме — PHP Assertions, с таким же вопросом в конце 🙂
В заключение
Я за вас напишу выводы из данной статьи:
Это репост из серии статей «PHP для начинающих»:
Спасибо Максиму Слесаренко за помощь в написании статьи.