You want access to information to help you debug database problems. For example, when a query fails, you want to see what error message the database returns.
Use PDO::errorCode( ) or PDOStatement::errorCode( ) after an operation to get an error code if the operation failed. The corresponding errorInfo( ) method returns more information about the error. Example 10-26 handles the error that results from trying to access a nonexistent table.
Printing error information
The errorCode( ) method returns a five-character error code. PDO uses the SQL 92 SQLSTATE error codes. By that standard, 00000 means "no error," so a call to errorCode( ) that returns 00000 indicates success.
The errorInfo( ) method returns a three-element array. The first element contains the five-character SQLSTATE code (the same thing that errorCode( ) returns). The second element is a database backend-specific error code. The third element is a database backend-specific error message.
Make sure to call errorCode( ) or errorInfo( ) on the same object on which you called the method that you're checking for an error. In Example 10-26, the prepare( ) method is called on the PDO object, so errorInfo( ) is called on the PDO object. If you want to check whether a fetch( ) called on a PDOStatement object succeeded, call errorCode( ) or errorInfo( ) on the PDOStatement object.
One exception to this rule is when creating a new PDO object. If that fails, PDO throws an exception. It does this because otherwise there'd be no object on which you could call errorCode( ) or errorInfo( ). The message in the exception details why the connection failed.
To have PDO throw exceptions every time it encounters an error, call setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION) on your PDO object after it's created. This way, you can handle database problems uniformly instead of larding your code with repeated calls to errorCode( ) and errorInfo( ). Example 10-27 performs a series of database operations wrapped inside a try/catch block.
Catching database exceptions
Handling PDO errors as exceptions is useful inside of transactions, too. If there's a problem with a query once the transaction's started, just roll back the transaction when handling the exception.
Similar to the exception error mode is the "warning" error mode. setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING) tells PDO to issue warnings when a database error is encountered. If you prefer to work with regular PHP errors instead of exceptions, this is the error mode for you. Set up a custom error handler with set_error_handler( ) to handle E_WARNING level events and you can deal with your database problems in the error handler.
Whatever the error mode, PDO throws an exception if the initial PDO object creation fails. When using PDO, it's an extremely good idea to set up a default exception handler with set_exception_handler( ). Without a default exception handler, an uncaught exception causes the display of a complete stack trace if display_errors is on. If an exception is thrown when connecting to the database, this stack trace may contain sensitive information, including database connection credentials.
10.10.4. See Also
Documentation on PDO::errorCode( ) at http://www.php.net/PDO::errorCode, on PDO::errorInfo( ) at http://www.php.net/PDO::errorInfo, on PDOStatement::errorCode( ) at http://www.php.net/PDOStatement::errorCode, on PDOStatement::errorInfo( ) at http://www.php.net/PDOStatement::errorInfo, on set_exception_handler( ) at http://www.php.net/set_exception_handler, and on set_error_handler( ) at http://www.php.net/set-error-handler. A list of some SQL 92 SQLSTATE error codes that PDO knows about is available at http://cvs.php.net/viewcvs.cgi/php-src/ext/pdo/pdo_sqlstate.c?view=markup, but some database backends may raise errors other than the ones listed .