Debugging PHPPHP's Error Handling Features
In the development phase of creating an application, having notices and errors
displayed in the browser is vital. When the project is live, though, displaying
errors to users is frequently undesirable, especially since error messages can
contain run-time information about the server and script. Depending on what
it is, this information can be a boon to potential hackers. This is just one
of the reasons that PHP provides flexible options for controlling when, how,
and which errors messages are displayed.
As you may have noticed from the sample error messages in the previous section, PHP divides syntax errors into three separate groups: Parse Errors, Notices and Warnings. Parse Errors are classified irrecoverable errors which stop the execution of the script, while Notices and Warnings are less serious and do not stop the script.
To allow the internal settings and functions to control how errors are reported, PHP assigns constants and values to each of the various types of errrors. The following have been available since PHP3:
The PHP.ini is the primary location for controlling error reporting options and contains several settings to manage them; including error_reporting, display_errors, and error_log.
The first, error_reporting, uses the constants listed above, and several logical
operators ("|","~", "!" and "&")
to build up an expression describing which errors should be displayed. For example,
the default setting in PHP4 is: E_ALL & ~E_NOTICE. This indicates that all
error messages should be shown, except for notices.
When set to "off", the display_errors suppresses all Parse Errors, Warnings, and Notices that would normally be sent to the browser. This setting works in conjunction with error_log, which allows you to specify that errors should be saved to the server's error log.
Errors reporting settings can also be set on a script-by-script basis using the error_reporting() function. The rules defined by this function are only in affect for as long as the script runs. This is especially useful in situations where you may want to display errors in a particular script for development and debugging, but suppress them once the script is ready to go live without making global changes in your PHP.ini. error_reporting() accepts constant names (the encouraged method) in combination, as in the PHP.ini, as well as their integer values:
|error_reporting(0); - turns off all error reporting.
error_reporting(E_ALL); - turns on all error reporting.
error_reporting(E_ERROR | E_WARNING); - shows critical errors and warnings only.
You can also suppress errors generated by a particular expression within a
script by including the proceeding it with the @ symbol. For example: @unlink($file);
Keep in mind that even if you supress errors through any of the above methods, a script will still stop executing should the PHP processor encounter a critical error.
A Note on Creating Your Own Error Messages
You may have noticed that some of the error constants in the previous section
referred to user created errors. Though beyond the scope of this article (and
the needs of most new PHP programmers), keep in mind that PHP also provides
advanced functions which allow you to create and impliment your own error messages.
For simple scripts the need to add custom error handling is questionable, but
in full-fledged applications the benefits become more apparent. By creating
your own error handling functions, you can control the output; for example,
you could provide contact information for the adminstrator of the server, or
redirect the user to another location. You could also send out an email to notify
you if a critical error had occured.
The set_error_handler() function allows you to build in this functionability to your own scripts.
Hopefully, this article has armed you with the knowledge to intelligently
manage and combat errors in your own scripts. Avoiding, and understanding how
to quickly troubleshoot errors in your work will greatly decrease the time it
takes to get a script from the development phase to afinished product.
In the next article, we will be taking a look at some more theory of programming with PHP, covering aspects of coding style.
Things to remember:
Liz Fulghum currently lives in Annapolis, MD where she works as a web designer for a custom shirt retailer. Liz was convinced to try PHP as an alternative to Perl; she has been a fan ever since and frequently works as a freelance developer.
# # #
Page 2 of 2