Without a doubt, the most important debugging feature I have ever used is the ability to send out emails when a database query fails. Echo’s and debugging environments are great locally, but don’t work on the live server. Likewise, logs and graceful error handling are useful, but don’t give you instant notifications with custom, detailed information. Now, receiving an email containing query, user, and PHP information the instant a problem happens is just pure beauty. Let’s outline how to go about implementing this into a database class.
A basic database class will just wrap the ability to execute a query in a function. We’re going to take that function, and check for errors. If an error is found, send out the proper email.
function query($sql, $line) {
$ret = false;
$rs = mysql_query($sql,$this->conn);
if (mysql_errno($this->conn)) {
$this->emailError($sql, mysql_error($this->conn), $line);
}
else $ret = true;
return $ret;
}
This function just takes a query and executes it, returning true or false depending on success. If false, an email gets sent, which we will get to. Here is how you would apply the function:
$db = new database();
$ret = $db->query('SELECT * FROM Users', __LINE__);
The nice part about this is that the __LINE__ constant will send the PHP line to the function, which aids in debugging. That way, we can send the email with all of the important information. Note that you can also get the file using the __FILE__ constant.
function emailError($sql, $error, $line) {
$headers = "From:You \r\n";
$headers .= "Reply-To:no-reply@yoursite.com\r\n".
"Content-type: text/html; charset=UTF-8\r\n";
$to = 'ryan@particletree.com';
$subject = 'Failed Database Query ';
$message = ""; $message .= "<b>Line</b><br />".
$line."<br /><br />"; $message .= "<b>Query</b><br />".
$sql."<br /><br />"; $message .= "<b>Error</b><br />".
$error."<br /><br />"; mail($to, $subject, $message, $headers);
}
This is all pretty straight forward, but it is an invaluable tool. In addition to the above, you can also include code specific items such as global, session, and local variable values. The next concern is with multiple developers. This functionality can email multiple people, but it would be interesting to try another technology, such as RSS. RSS is easily parsable, which would allow integration into other system, such as bug trackers. It would also allow for new developers to subscribe to errors without having to modify the code and add their email. Considering that I feel this is the most valuable debugging technique, it might be worth trying to take it further and develop upon it.
I’d like to use set_error_handler to overrule the default error handler and create my own. This way, I can show an “oops something bad happened” page, while (possibly) mailing me and fellow developers an extensive error report.
By overriding PHP’s error handler you’ll also get the line number and besides that even more handy information like the error type (warning, notice, etc) and file in which the error occured. In combination with the debug_backtrace function() in PHP, you can make some excellent custom error handlers.
Simple but sweet.
I also use debug_backtrace() trickery to grab the line and file: saves you from having to manually pass the constants. However, I use it for a different purpose…
Schlossnagle has this to say about emailing errors (and I paraphrase): The thing about it is that errors tend to occur in clumps. That means that your nifty error handler might end up sending 1000 emails to you before you get in and shut it off. RSS might make more sense, but then again, what you’d probably want to do is log the error, and then have the RSS generator parse the log.
I agree that early on errors come in clumps, but it tends to slow down. It would actually make sense to add the ability to turn emailing on and off for specific files. If a feature is just released, you may want to turn them off until a lot of testing has occured. But for stable portions of a product, I imagine the amount of emails would still be reasonable.
I also find that known bugs in stable portions of the product will get fixed faster if I am reminded 20 times a day via email that a problem happened.
If you’re worried about lots of mail messages going out, a better way to deal with this sort of thing might be to hook it in to your network monitoring system. When the status of your “database queries” object in the monitoring system goes yellow (or red, or whatever), you can have the monitoring system deal with sending an e-mail, escalating appropriately, and so on. Click on it to see the issues, and the deal with them as necessary, and clear the alert.
For this particular thing, though, I have to say I’ve not over the past few years been having database queries fail in production. I attribute this to a couple of things: using PostgreSQL with appropriate constraints (so that it’s not possible for invalid data to get into the DB), and a comprehensive automated test framework that ensures that every query is well tested.
I would just use a custom error handler and log the error message and stack dump to a file/database. Emailing gets annoying. This article does get people thinking though. :)
~Cody http://www.threadbound.com