Building A Generic Error Reporting Class In PHP - The Number Game

(Page 5 of 9 )

Right. So I now know how the class is supposed to work, plus I have a fairly good idea of what the methods encapsulated within it will look like. This is a good time to start writing some code.

You might find it helpful to download the complete class code at this point, so that you can refer to it over the next few pages.

errorReporter.zip

Let's begin by setting up the class definition:

// errorReporter.class.php
// class to capture and display errors in a consistent 
manner
class errorReporter
{
// snip
}

Now, since I plan to build some basic error-handling routines into this class, I need to add a variable to hold this information.

<?php
class errorReporter
{
//
// private variables
//
var $_errors 
= array();
// snip
}

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:

<?php
class errorReporter
{
// define main error types (add to this list 
as per your
requirements)
// < 1000 are fatal (script stops immediately)
// 
> 1000 are non-fatal (script stops once all non-fatals have
been
processed)
var 
$_errorTypes = array(
100 => "Database error",
200 => "File I/O error",
300 
=> "Authentication error",
400 => "Script error",
1100 => "Form error",
1200 
=> "URL error"
);
// snip
}

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:

<?php
class errorReporter
{
// error subtypes
// linked to above via primary 
type
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 
not 
copy file(s)",
203 => "Could not execute command",
204 => "Could not read 
configuration 
file",
205 => "Could not delete file(s)",
206 => "Could not 
read 
file(s)",
207 
=> "Could not write file(s)",
208 => "Could not open file(s)",
209 
=> "File 
already exists",
210 => "Could not delete directory",
301 => "Session 
expired",
401 
=> "An internal script error occurred",
1101 => "Required 
field 
empty",
1102 
=> "Invalid data in field",
1103 => "File upload unsuccessful",
1201 
=> "Missing 
record identifier(s)"
);
// snip
}

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.

Next: Running On Empty >>
 

More PHP Articles
More By icarus, (c) Melonfire

Comments On: Building A Generic Error Reporting Class In PHP

>>> Be the FIRST to comment on this article!