HomePHP Page 2 - Error and Exception Handling in PHP
Configuration Directives - PHP
Mistakes are inevitable, in life, programming, and application submissions. You can prepare for errors by making sure your application is designed to respond to them. This two-part article explains how PHP handles errors. It is excerpted from chapter 8 of the book Beginning PHP and Oracle: From Novice to Professional, written by W. Jason Gilmore and Bob Bryla (Apress; ISBN: 1590597702).
Numerous configuration directives determine PHP’s error-reporting behavior. Many of these directives are introduced in this section.
Setting the Desired Error Sensitivity Level
Theerror_reportingdirective determines the reporting sensitivity level. Fourteen separate levels are available, and any combination of these levels is valid. See Table 8-1 for a complete list of these levels. Note that each level is inclusive of all levels residing below it. For example, theE_ALLlevel reports any messages resulting from the 13 other levels residing below it in the table.
Table 8-1. PHP’s Error-Reporting Levels
All errors and warnings
Fatal compile-time errors
Fatal errors that occur during PHP’s initial start
Warnings that occur during PHP’s initial start
Fatal run-time errors
Compile-time parse errors
Near-fatal errors (introduced in PHP 5.2)
PHP version portability suggestions (introduced in PHP 5.0)
Introduced in PHP 5,E_STRICTsuggests code changes based on the core developers’ determinations as to proper coding methodologies and is intended to ensure portability across PHP versions. If you use deprecated functions or syntax, use references incorrectly, usevarrather than a scope level for class fields, or introduce other stylistic discrepancies,E_STRICTcalls it to your attention. In PHP 6,E_STRICTis integrated intoE_ALL; therefore, when running PHP 6, you’ll need to set theerror_reportingdirective toE_ALLin order to view these portability suggestions.
Note Theerror_reportingdirective uses the tilde character (~) to represent the logical operatorNOT.
During the development stage, you’ll likely want all errors to be reported. Therefore, consider setting the directive like this:
error_reporting = E_ALL
However, suppose that you were only concerned about fatal run-time, parse, and core errors. You could use logical operators to set the directive as follows:
error_reporting E_ERROR | E_PARSE | E_CORE_ERROR
As a final example, suppose you want all errors reported except for user-generated ones:
As is often the case, the name of the game is to remain well-informed about your application’s ongoing issues without becoming so inundated with information that you quit looking at the logs. Spend some time experimenting with the various levels during the development process, at least until you’re well aware of the various types of reporting data that each configuration provides.