Приглашаем посетить
Лермонтов (lermontov-lit.ru)

Chapter 3.  Error Handling

Previous
Table of Contents
Next

3. Error Handling

ERRORS ARE A FACT OF LIFE. Mr. Murphy has an entire collection of laws detailing the prevalence and inescapability of errors. In programming, errors come in two basic flavors:

  • External errors These are errors in which the code takes an unanticipated path due to a part of the program not acting as anticipated. For example, a database connection failing to be established when the code requires it to be established successfully is an external error.

  • Code logic errors These errors, commonly referred to as bugs, are errors in which the code design is fundamentally flawed due to either faulty logic ("it just doesn't work that way") or something as simple as a typo.

These two categories of errors differ significantly in several ways:

  • External errors will always occur, regardless of how "bug free" code is. They are not bugs in and of themselves because they are external to the program.

  • External errors that aren't accounted for in the code logic can be bugs. For example, blindly assuming that a database connection will always succeed is a bug because the application will almost certainly not respond correctly in that case.

  • Code logic errors are much more difficult to track down than external errors because by definition their location is not known. You can implement data consistency checks to expose them, however.

PHP has built-in support for error handling, as well as a built-in severity system that allows you to see only errors that are serious enough to concern you. PHP has three severity levels of errors:

  • E_NOTICE

  • E_WARNING

  • E_ERROR

E_NOTICE errors are minor, nonfatal errors designed to help you identify possible bugs in your code. In general, an E_NOTICE error is something that works but may not do what you intended. An example might be using a variable in a non-assignment expression before it has been assigned to, as in this case:

<?php
    $variable++;
?>

This example will increment $variable to 1 (because variables are instantiated as 0/false/empty string), but it will generate an E_NOTICE error. Instead you should use this:

<?php
    $variable = 0;
    $variable++;
?>

This check is designed to prevent errors due to typos in variable names. For example, this code block will work fine:

<?php
    $variable = 0;
    $variabel++;
?>

However, $variable will not be incremented, and $variabel will be. E_NOTICE warnings help catch this sort of error; they are similar to running a Perl program with use warnings and use strict or compiling a C program with -Wall.

In PHP, E_NOTICE errors are turned off by default because they can produce rather large and repetitive logs. In my applications, I prefer to turn on E_NOTICE warnings in development to assist in code cleanup and then disable them on production machines.

E_WARNING errors are nonfatal runtime errors. They do not halt or change the control flow of the script, but they indicate that something bad happened. Many external errors generate E_WARNING errors. An example is getting an error on a call to fopen() to mysql_connect().

E_ERROR errors are unrecoverable errors that halt the execution of the running script. Examples include attempting to instantiate a non-existent class and failing a type hint in a function. (Ironically, passing the incorrect number of arguments to a function is only an E_WARNING error.)

PHP supplies the TRigger_error() function, which allows a user to generate his or her own errors inside a script. There are three types of errors that can be triggered by the user, and they have identical semantics to the errors just discussed:

  • E_USER_NOTICE

  • E_USER_WARNING

  • E_USER_ERROR

You can trigger these errors as follows:

while(!feof($fp)) {
  $line = fgets($fp);
  if(!parse_line($line)) {
    trigger_error("Incomprehensible data encountered", E_USER_NOTICE);
  }
}

If no error level is specified, E_USER_NOTICE is used.

In addition to these errors, there are five other categories that are encountered somewhat less frequently:

  • E_PARSE The script has a syntactic error and could not be parsed. This is a fatal error.

  • E_COMPILE_ERROR A fatal error occurred in the engine while compiling the script.

  • E_COMPILE_WARNING A nonfatal error occurred in the engine while parsing the script.

  • E_CORE_ERROR A fatal runtime error occurred in the engine.

  • E_CORE_WARNING A nonfatal runtime error occurred in the engine.

In addition, PHP uses the E_ALL error category for all error reporting levels. You can control the level of errors that are percolated up to your script by using the php.ini setting error_reporting. error_reporting is a bit-field test set that uses defined constants, such as the following for all errors:

error_reporting = E_ALL

error_reporting uses the following for all errors except for E_NOTICE, which can be set by XOR'ing E_ALL and E_NOTICE:

error_reporting = E_ALL ~ E_NOTICE

Similarly, error_reporting uses the following for only fatal errors (bitwise OR of the two error types):

error_reporting = E_ERROR | E_USER_ERROR

Note that removing E_ERROR from the error_reporting level does not allow you to ignore fatal errors; it only prevents an error handler from being called for it.


Previous
Table of Contents
Next