Error Levels in PHP

Parse Errors

This set of errors is reported as a result of syntax errors. Since PHP3 executes scripts line-by-line, a PHP3 parser reports these errors only when it encounters the erroneous statement. However, PHP4 reports parse errors early during the compilation stage of the script. With PHP4, scripts with parse errors do not compile much less execute. To enable parse errors to be reported, the E_PARSE constant should be used as an argument to the error_reporting() function.

Fatal Errors

The execution environment reports fatal errors when it cannot recover from an error condition. Fatal errors are often reported as a result of errors not handled, semantic errors, and environmental errors. For example, if a file is missing at the location specified by the require() directive, then a fatal error is reported and the program bails out. The E_ERROR constant can be used to enable reporting of an error at this level.

Warnings

Warnings are reported when a non-fatal condition occurs which does not require the script to terminate execution. An example of a warning is when an include() statement cannot locate the specified file. This would cause a warning if the condition were not gracefully handled by the program's logic. A warning does not mean that the execution environment, in line with the program's logic, has intelligently handled the error. Scripts must be corrected to programmatically handle conditions that cause warnings. The E_WARNING constant can be used to enable reporting of warning-level errors.

Notices

The execution environment often issues notices when it encounters erroneous conditions that it can recover on its own. An example is a variable that is not initialized. Since PHP assigns a default value when operations are performed on such variables, these do not result in fatal conditions requiring termination of the script. E_NOTICE can be used to enable reporting notice-level errors.

Core Errors

Core errors are those that are generated by the PHP core. User defined functions should not generate an error at these levels. E_CORE_ERROR and E_CORE_WARNING are the two core error levels.

Compile Errors

The underlying Zend scripting engine generates an error at these levels. Just as with core level errors, these errors should not be generated by user-defined functions. The compile error levels are E_COMPILE_ERROR and E_COMPILE_WARNING and they are similar to E_ERROR and E_WARNING, except of course that they are generated by the Zend scripting engine.

User Error Levels

Often applications need to report errors at a level other than any of the ones reported above. The user error levels fulfil this requirement. The user error levels are E_USER_ERROR, E_USER_WARNING, and E_USER_NOTICE. These are analogous to E_ERROR, E_WARNING, and E_NOTICE respectively. The trigger_error() function can be used to generate an error at this level; however, user-defined functions should not generate an error at these levels.

Setting Error Reporting Levels

While error reporting is useful for debugging programs, it might not be necessary to display the error messages to the end user. The error reporting level can be set using the error_reporting() function. The function declaration is:

    int error_reporting(int level);

level is indicated by one of the E_ constants mentioned in the earlier section. It is possible to set more than one error level at the same time by combining the constants with the bit wise "|" operator. Thus to enable reporting of notice and warning level errors, the error_reporting() function would be called as opposite:

    error_reporting(E_WARNING | E_NOTICE);

The return value of the error_reporting() function is the earlier error reporting level. This value can be stored in a variable before changing the error reporting level, to be used later to revert to the earlier error reporting level. To enable error reporting at all levels, the E_ALL constant may be used. Setting the level to 0 turns off all error reporting. It is usually a good idea to set the error reporting level to the maximum (E_ALL) during the development phase, but to keep it to 0 or a much lower level when in production. For production deployments, error conditions should be handled gracefully and logged rather than displayed. We shall examine the topics of error handling and logging next.