PHP Error Handling – Part One, Error Types & Exceptions


As a study aid whilst working towards Zend Certification and also due to a post on the topic being requested by a colleague (Barry) and after a rant by me after a talk at PHP UK 2012, here is the first of three posts on errors in PHP.

While most languages have just one or a few ways of reporting errors, PHP has many. This can make the whole process of handling errors seem confusing or even broken, but in fact this abundance can allow for some very specific error reporting.

This post will attempt to describe PHP’s error types and exception throwing simply and give examples of how they can be generated at runtime. This example code will then form a series of tests for the standard and custom error reporting functionality which will form the topics of part two and three in this series on errors. This should help ensure that we handle every error type as well as uncaught exceptions.

The Error Types

There are three effective levels of error type in PHP:

  • Error – A non-recoverable error, execution should always be stopped, these are E_ERROR, E_CORE_ERROR, E_COMPILE_ERROR and E_USER_ERROR.
  • Warning – A recoverable error, these are E_WARNING, E_CORE_WARNING, E_COMPILE_WARNING and E_USER_WARNING
  • Notice – An error has occurred, which may not affect execution, these are E_NOTICE, E_USER_NOTICE, E_STRICT, E_DEPRECATED and E_USER_DEPRECATED

The error type E_RECOVERABLE_ERROR introduced in PHP 5.3 represent errors which are fatal (E_ERROR) if not handled by a custom error handler.

Additionally there is also E_PARSE which is a compile-time error and should only come from the parser, usually this type of error can be avoided all together by using a syntax checker for PHP in an editor / IDE.

One of the most used predefined error constants is E_ALL, this is not an error type in itself but represents all of the other error types in aggregate (except E_STRICT before PHP 5.4). This constant is commonly used with the standard error reporting functions which we will see in part two.

As well as the errors being of different severity the error types within each level can give an indication of why the error occured. Core errors occur in the PHP core and compile errors in the Zend engine, these should never really occur in day-to-day use (I cannot recall ever having encountered them). The E_USER_* error family are generated at run time using the trigger_error function by the user, with the message accompanied with one of the user error types. Deprecated errors (since PHP 5.3) are notifications of features which are being phased out of PHP and are unlikely to appear in later releases.

A note on bitwise operators: When setting PHP’s error_reporting directive (covered in part two) error types can be combined / ommitted using bitwise operators (the integer values for all of the error types are factors of two), this is how the E_ALL type (with a value of 32767) manages to encompass all of the other error types. You can read more about bitwise operators and error constants here.

It is also worth noting that in PHP there is an Error Control Operator, which is ‘@’. When any expression is prepended with the operator, errors in the expression will be ignored, that is not to say that script execution will continue however, fatal errors will still kill execution but you will not be told why. Generally speaking this operator should be avoided unless you are wanting to check for / handle any errors yourself (so that perhaps you could use some kind of fallback for example).

Here are all of the error types, with their predefined constant name, integer value and example of how they can be caused (where appropriate). This code can be included in any project, with each error example being uncommented to test a particular error types’ handling.

Exceptions

PHP has come a long way since it’s ‘Personal Home Page’ days and has expanded into the world of Object Orientated Programming (OOP) and with this has come exceptions. In OOP when an error occurs an exception is ‘thrown’, this should occur within a try block of code which will then be ‘caught’ by a corresponding catch block. Execution at the point of error stops and continues within the catch block, if try / catch blocks are not implemented than this can lead to OOP code throwing an ‘uncaught’ exception, we will need to implement handling of these.

Below is an example code which could cause an uncaught exception as well as a well formed try / catch block, which will handle any exception thrown in the try block in the corresponding catch block .

Note: I may well come back to this post to add more information while working on parts two and three if anything pertinent arises. Feel free to comment if there is anything which you feel should be added / fixed.

References / Further Reading:

About Ingmar Boddington

Codemonkey, Sheffield, UK
This entry was posted in PHP and tagged Error Handling, Exceptions, PHP. Bookmark the permalink.