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.
Next: How Things Work >>
More PHP Articles
More By icarus, (c) Melonfire
/ 19 
