HomePHP Page 5 - Building A Generic Error Reporting Class In PHP
The Number Game - PHP
The traditional method of building dynamic, PHP-based Web sites - mixing HTML elements with PHP code - can result in mangled Web pages (and much user angst) if errors take place during script execution. But yes, you can avoid the ugliness - plug in our handy error reporting class, which provides a simple way of trapping script errors and generating consistent, user-friendly error screens.
// class to capture and display errors in a consistent
Now, since I plan to build some basic error-handling routines into this class,
I need to add a variable to hold this information.
// private variables
Note the underscore (_) prefixed to this variable; I've done this in order to
provide a convenient way to visually distinguish between private and public class variables and functions.
You'll remember, from my explanation on the previous page, that the errorReporter class allows developers to manually trigger two types of errors - fatal and non-fatal - using a unique error code. Let's define this list of error codes next:
// define main error types (add to this list
as per your
// < 1000 are fatal (script stops immediately)
> 1000 are non-fatal (script stops once all non-fatals have
$_errorTypes = array(
100 => "Database error",
200 => "File I/O error",
=> "Authentication error",
400 => "Script error",
1100 => "Form error",
=> "URL error"
As you can see, I've defined six main error categories, each with a unique identifying
code. I've also further classified these error categories into "fatal" and "non-fatal" - that is, errors which should cause immediate script termination, such as a failed database connection or a bad file operation, and errors which are not so serious, such as missing form data (more on this later). Categories with error codes below 1000 are considered fatal, the remaining categories are considered non-fatal.
This list is not exhaustive - you should edit it as per your own needs. The categories above have been created on the basis of my own past experience with Web application errors.
With this broad categorization in mind, it's possible to go down one level further, and define more specific error messages within each category. Take a look:
// error subtypes
// linked to above via primary
var $_errorsubTypes = array(
101 => "Error in SQL query",
102 => "Could
not connect to database server",
103 => "Database already exists",
104 => "Could
not select database",
201 => "Could not create directory",
202 => "Could
203 => "Could not execute command",
204 => "Could not read
205 => "Could not delete file(s)",
206 => "Could not
=> "Could not write file(s)",
208 => "Could not open file(s)",
210 => "Could not delete directory",
301 => "Session
=> "An internal script error occurred",
1101 => "Required
=> "Invalid data in field",
1103 => "File upload unsuccessful",
This pre-defined list of error codes and messages covers the most common errors
developers experience when building Web applications. Since this list is defined once, and indexed by a unique numeric code, it may be reused over and over, in different scripts, to display consistent error messages. And in the event that a particular error message is deemed confusing or difficult to understand, all you need to do is update this master list, and the change will be immediately reflected across all error screens thrown up by the application.