Solution: Recover from Errors Gracefully
Let’s learn how we can recover from the missteps taken.
We'll cover the following
Anyone who enjoys dancing knows that missteps are inevitable. The secret to remaining graceful is to understand how to recover. We must give ourselves a chance to notice the cause of the mistake. Then we can react quickly and seamlessly, getting back into rhythm before anyone has seen our gaffe.
Maintain the rhythm#
Checking return status and exceptions from database API calls is the best way to ensure that we haven’t missed a step. The following example shows code that checks the status after each call that could cause an error:
<?php
try {
＄pdo = new PDO("mysql:dbname=test;host=localhost",
"dbuser", "dbpassword");
} catch (PDOException ＄e) { //1
report_error(＄e->getMessage());
return;
}
＄sql = "SELECT bug_id, summary, date_reported FROM Bugs
WHERE assigned_to = ? AND status = ?";
if ((＄stmt = ＄pdo->prepare(＄sql)) === false) { //2
＄error = ＄pdo->errorInfo();
report_error(＄error[2]);
return;
}
if (＄stmt->execute(array(1, "OPEN")) === false) { //3
＄error = ＄stmt->errorInfo();
report_error(＄error[2]);
return;
}
if ((＄bug = ＄stmt->fetch()) === false) { //4
＄error = ＄stmt->errorInfo();
report_error(＄error[2]);
return;
}
?>
The code at point 1 catches the exception that is thrown if a database connection fails. The other functions return false when there’s a problem. After checking for a problem at points 2, 3, and 4, we can get more information from the database connection object or the statement object.
Retrace your steps#
It’s also essential to use the actual SQL query to debug a problem instead of the code that produces an SQL query. Many simple mistakes, such as misspellings or imbalanced quotes or parentheses, are apparent instantly, even though they’re obscure and puzzling otherwise.
It’s better to build our SQL query in a variable instead of building it ad hoc in the arguments of the API method to prepare the query. This gives us the opportunity to examine the variable before we use it.
We can choose a place to output SQL that is not part of our application output, such as a log file, an IDE debugger console, or a browser extension, to show diagnostic output. Firebug is a good example of this.
We should also not print the SQL query within HTML comments of a web application’s output. Any user can view our page source. Reading the SQL query gives hackers a lot of knowledge about our database structure.
Using an object-relational mapping (ORM) framework that builds and executes SQL queries transparently can make debugging complicated. If we don’t have access to the content of the SQL query, how can we observe it for debugging? Some ORM frameworks solve this by sending generated SQL to a log.
Finally, most database brands provide their own logging mechanism on the database servers instead of in the application client code. If we can’t enable SQL logging in the application, we can still monitor queries as the database server executes them.
