Building A Generic Error Reporting Class In PHP - The Bare Bones (
Page 3 of 9 )
So that's the theory. Let's now spend a few
minutes discussing the rationale behind the errorReporter object I plan to build.
Consider the following script, which is representative of the way many PHP applications
are coded:
<html>
<head>
<basefont face="Verdana">
</head>
<body>
<p>
<p>
<table width="100%" border="0" cellspacing="0" cellpadding="5"
bgcolor="Navy">
<tr>
<td bgcolor="Navy" width="100%"><font
color="white"><b>Welcome!</b></font></td>
</tr>
</table>
<p>
<!--
3-column table -->
<table width="100%" border="0" cellspacing="0" cellpadding="5">
<tr>
<!-- column 1 -->
<td width="10%">
<table height="250" width="100%"
border="1"
cellspacing="0" cellpadding="5">
<tr>
<td valign="top" height="10">
<font
size="-1">
Pick a store:
</font>
</td>
</tr>
<tr>
<td
valign="top">
<font
size="-1">
<ul>
<li><a href="#">Men</a>
<li><a
href="#">Women</a>
<li><a
href="#">Children</a>
</ul>
</font>
</td>
</tr>
</table>
</td>
<!--
column 2 -->
<td valign="top" width="80%">
<table>
<tr>
<td
align="center"
valign="top">
<b>We're having a special Thanksgiving sale,
with up to
60%
off on selected items. Come on in and check it out!</b>
</td>
</tr>
<?
//
get 3 featured items
// open connection to database
$connection = mysql_connect("localhost",
"user", "pass")
or die ("Unable to connect!");
mysql_select_db("store") or
die
("Unable to select
database!");
// formulate and execute query
$query
=
"SELECT
id, label, desc, price,img_small FROM
catalog LIMIT 0,3";
$result
=
mysql_query($query)
or die ("Error in query:
$query. " . mysql_error());
//
iterate through result
set
// and print data for each item
// data consists
of image, description,
item
ID and
price
while(list($id, $label, $desc, $price,
$img) =
mysql_fetch_row($result))
{
?>
<tr>
<td>
<img
src="<? echo $img; ?>">
</td>
<td>
<a
href="details.php?id=<?
echo $id; ?>"><? echo
$label; ?></a>
<br>
<?
echo $desc; ?>
<br>
<i>Only
<? echo $price; ?></i>
</td>
</tr>
<?
}
//
clean
up
mysql_close($connection);
?>
</table>
</td>
<!--
column 3 -->
<td width="10%">
<table height="250" width="100%" border="0"
cellspacing="0"
cellpadding="5">
<tr>
<td valign="top">
<font size="-1">
Visit
our
sponsor:
</font>
<?
// get sponsor banner
// open connection
to database
$connection
= mysql_connect("localhost", "user", "pass")
or die
("Unable to connect!");
mysql_select_db("clients")
or die ("Unable to select
database!");
//
formulate and execute query
$query
= "SELECT bid, banner, url FROM ads WHERE
status=1
LIMIT 0,1";
$result = mysql_query($query)
or die ("Error in query:
$query.
"
. mysql_error());
// use result set
list($bid,
$banner, $url) = mysql_fetch_row($result);
//
clean up
mysql_close($connection);
//
display banner
?>
<a href="click.php?bid=<?
echo $bid; ?>"><img src="<?
echo
$banner;
?>"></a>
</td>
</tr>
</table>
</td>
</tr>
</table>
</body>
</html>
As you can see, this script dynamically builds an HTML page, using PHP to generate
some components of the data that appears on the page. The PHP business logic is
closely intertwined with the HTML interface code, and is executed sequentially,
line by line, as the PHP engine parses the document.
Now, consider what happens if an error occurs during execution of the PHP functions
near the middle of the script - say, for example, the database server does down.
Here's what the resulting output might look like:
Ugly, huh?
Obviously, if you're in the business of building professional Web applications,
an incomplete page like the one above opens the door to a minefield of problems
- possible further errors if the user attempts to invoke a command on the incomplete
page, support calls if the error message is particularly difficult to understand
(or absent), and so on. Therefore, it makes sense to ensure that such errors,
if they occur, are handled in a graceful manner, with a consistent error screen
displayed to the user and no potential to further compound the mistake.
Further, it is possible to classify the errors that occur within an application
into two basic categories: serious ("fatal") errors that require the script to
terminate immediately, such as a broken database connection or a file I/O error,
and less serious ("non-fatal") errors that do not require the script to terminate
immediately, such as missing or incorrectly-typed form data.
Keeping this in mind, it's possible to create a simple class that handles error
reporting gracefully, producing consistent error messages so that users are protected
from the situation described a few pages back. This errorReporter class would
consist of the following three components:
- Methods that allows the developer to raise, or trigger, errors whenever required,
and to add these errors to an "error stack". This error stack is merely a PHP
structure (here, an associative array) that holds a list of all the errors (both
fatal and non-fatal) encountered.
- Methods that may be called by the developer to clear the screen of previously-generated
data and re-draw it with an error message (this is necessary to avoid the display
of incomplete pages, such as the one above). Fatal errors are reported immediately;
reporting of non-fatal errors may be controlled by the developer.
- Utility methods to manipulate the error stack.
As you will see, these three basic components make it possible to build a very
simple (and yet very useful) errorReporter object.
/ 20 
