These are functions dealing with error handling and logging. They allow you to define your own error handling rules, as well as modify the way the errors can be logged. This allows you to change and enhance error reporting to suit your needs.
With the logging functions, you can send messages directly to other machines, to an email (or email to pager gateway!), to system logs, etc., so you can selectively log and monitor the most important parts of your applications and websites.
The error reporting functions allow you to customize what level and kind of error feedback is given, ranging from simple notices to customized functions returned during errors.
No external libraries are needed to build this extension.
There is no installation needed to use these functions; they are part of the PHP core.
The behaviour of these functions is affected by settings in php.ini.
Table 1. Errors and Logging Configuration Options
|error_reporting||E_ALL & ~E_NOTICE||PHP_INI_ALL|
Here's a short explanation of the configuration directives.
Set the error reporting level. The parameter is either an integer representing a bit field, or named constants. The error_reporting levels and constants are described in Predefined Constants, and in php.ini. To set at runtime, use the error_reporting() function. See also the display_errors directive.
In PHP 4 and PHP 5 the default value is E_ALL & ~E_NOTICE. This setting does not show E_NOTICE level errors. You may want to show them during development.
Note: Enabling E_NOTICE during development has some benefits. For debugging purposes: NOTICE messages will warn you about possible bugs in your code. For example, use of unassigned values is warned. It is extremely useful to find typos and to save time for debugging. NOTICE messages will warn you about bad style. For example, $arr[item] is better to be written as $arr['item'] since PHP tries to treat "item" as constant. If it is not a constant, PHP assumes it is a string index for the array.
Note: In PHP 5 a new error level E_STRICT is available. As E_STRICT is not included within E_ALL you have to explicitly enable this kind of error level. Enabling E_STRICT during development has some benefits. STRICT messages will help you to use the latest and greatest suggested method of coding, for example warn you about using deprecated functions.
In PHP 3, the default setting is (E_ERROR | E_WARNING | E_PARSE), meaning the same thing. Note, however, that since constants are not supported in PHP 3's php3.ini, the error_reporting setting there must be numeric; hence, it is 7.
This determines whether errors should be printed to the screen as part of the output or if they should be hidden from the user.
Note: This is a feature to support your development and should never be used on production systems (e.g. systems connected to the internet).
Even when display_errors is on, errors that occur during PHP's startup sequence are not displayed. It's strongly recommended to keep display_startup_errors off, except for debugging.
Tells whether script error messages should be logged to the server's error log or error_log. This option is thus server-specific.
Note: You're strongly advised to use error logging in place of error displaying on production web sites.
Set the maximum length of log_errors in bytes. In error_log information about the source is added. The default is 1024 and 0 allows to not apply any maximum length at all. This length is applied to logged errors, displayed errors and also to $php_errormsg.
Do not log repeated messages. Repeated errors must occur in the same file on the same line until ignore_repeated_source is set true.
Ignore source of message when ignoring repeated messages. When this setting is On you will not log errors with repeated messages from different files or sourcelines.
If this parameter is set to Off, then memory leaks will not be shown (on stdout or in the log). This has only effect in a debug compile, and if error_reporting includes E_WARNING in the allowed list
If enabled, the last error message will always be present in the variable $php_errormsg.
Turn off HTML tags in error messages. The new format for HTML errors produces clickable messages that direct the user to a page describing the error or function in causing the error. These references are affected by docref_root and docref_ext.
The new error format contains a reference to a page describing the error or function causing the error. In case of manual pages you can download the manual in your language and set this ini directive to the URL of your local copy. If your local copy of the manual can be reached by '/manual/' you can simply use docref_root=/manual/. Additional you have to set docref_ext to match the fileextensions of your copy docref_ext=.html. It is possible to use external references. For example you can use docref_root=http://manual/en/ or docref_root="http://landonize.it/?how=url&theme=classic&filter=Landon &url=http%3A%2F%2Fwww.php.net%2F"
Most of the time you want the docref_root value to end with a slash '/'. But see the second example above which does not have nor need it.
Note: This is a feature to support your development since it makes it easy to lookup a function description. However it should never be used on production systems (e.g. systems connected to the internet).
Note: The value of docref_ext must begin with a dot '.'.
String to output before an error message.
String to output after an error message.
Name of the file where script errors should be logged. The file should be writable by the web server's user. If the special value syslog is used, the errors are sent to the system logger instead. On Unix, this means syslog(3) and on Windows NT it means the event log. The system logger is not supported on Windows 95. See also: syslog().
If enabled, this option makes PHP output a warning when the plus (+) operator is used on strings. This is to make it easier to find scripts that need to be rewritten to using the string concatenator instead (.).
The constants below are always available as part of the PHP core.
Note: You may use these constant names in php.ini but not outside of PHP, like in httpd.conf, where you'd use the bitmask values instead.
Table 2. Errors and Logging
|1||E_ERROR (integer)||Fatal run-time errors. These indicate errors that can not be recovered from, such as a memory allocation problem. Execution of the script is halted.|
|2||E_WARNING (integer)||Run-time warnings (non-fatal errors). Execution of the script is not halted.|
|4||E_PARSE (integer)||Compile-time parse errors. Parse errors should only be generated by the parser.|
|8||E_NOTICE (integer)||Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.|
|16||E_CORE_ERROR (integer)||Fatal errors that occur during PHP's initial startup. This is like an E_ERROR, except it is generated by the core of PHP.||since PHP 4|
|32||E_CORE_WARNING (integer)||Warnings (non-fatal errors) that occur during PHP's initial startup. This is like an E_WARNING, except it is generated by the core of PHP.||since PHP 4|
|64||E_COMPILE_ERROR (integer)||Fatal compile-time errors. This is like an E_ERROR, except it is generated by the Zend Scripting Engine.||since PHP 4|
|128||E_COMPILE_WARNING (integer)||Compile-time warnings (non-fatal errors). This is like an E_WARNING, except it is generated by the Zend Scripting Engine.||since PHP 4|
|256||E_USER_ERROR (integer)||User-generated error message. This is like an E_ERROR, except it is generated in PHP code by using the PHP function trigger_error().||since PHP 4|
|512||E_USER_WARNING (integer)||User-generated warning message. This is like an E_WARNING, except it is generated in PHP code by using the PHP function trigger_error().||since PHP 4|
|1024||E_USER_NOTICE (integer)||User-generated notice message. This is like an E_NOTICE, except it is generated in PHP code by using the PHP function trigger_error().||since PHP 4|
|2047||E_ALL (integer)||All errors and warnings, as supported, except of level E_STRICT.|
|2048||E_STRICT (integer)||Run-time notices. Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.||since PHP 5|
The above values (either numerical or symbolic) are used to build up a bitmask that specifies which errors to report. You can use the bitwise operators to combine these values or mask out certain types of errors. Note that only '|', '~', '!', '^' and '&' will be understood within php.ini, however, and that no bitwise operators will be understood within php3.ini.
Below we can see an example of using the error handling capabilities in PHP. We define an error handling function which logs the information into a file (using an XML format), and e-mails the developer in case a critical error in the logic happens.
Example 1. Using error handling in a script