Home arrow PHP arrow 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.

  1. Building A Generic Error Reporting Class In PHP
  2. Back To Class
  3. The Bare Bones
  4. How Things Work
  5. The Number Game
  6. Running On Empty
  7. Raising An Alarm
  8. A Well-Formed Idea
  9. Going To The Source
By: icarus, (c) Melonfire
Rating: starstarstarstarstar / 21
December 11, 2002

print this article


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.


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.

>>> More PHP Articles          >>> More By icarus, (c) Melonfire

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort


- Hackers Compromise PHP Sites to Launch Attac...
- Red Hat, Zend Form OpenShift PaaS Alliance
- PHP IDE News
- BCD, Zend Extend PHP Partnership
- PHP FAQ Highlight
- PHP Creator Didn't Set Out to Create a Langu...
- PHP Trends Revealed in Zend Study
- PHP: Best Methods for Running Scheduled Jobs
- PHP Array Functions: array_change_key_case
- PHP array_combine Function
- PHP array_chunk Function
- PHP Closures as View Helpers: Lazy-Loading F...
- Using PHP Closures as View Helpers
- PHP File and Operating System Program Execut...
- PHP: Effects of Wrapping Code in Class Const...

Developer Shed Affiliates


Dev Shed Tutorial Topics: