Errors and error handling

PDO offers you a choice of 3 different error handling strategies, to fit your style of application development.


    This is the default mode. PDO will simply set the error code for you to inspect using the PDO::errorCode() and PDO::errorInfo() methods on both the statement and database objects; if the error resulted from a call on a statement object, you would invoke the PDOStatement::errorCode() or PDOStatement::errorInfo() method on that object. If the error resulted from a call on the database object, you would invoke those methods on the database object instead.


    In addition to setting the error code, PDO will emit a traditional E_WARNING message. This setting is useful during debugging/testing, if you just want to see what problems occurred without interrupting the flow of the application.


    In addition to setting the error code, PDO will throw a PDOException and set its properties to reflect the error code and error information. This setting is also useful during debugging, as it will effectively "blow up" the script at the point of the error, very quickly pointing a finger at potential problem areas in your code (remember: transactions are automatically rolled back if the exception causes the script to terminate).

    Exception mode is also useful because you can structure your error handling more clearly than with traditional PHP-style warnings, and with less code/nesting than by running in silent mode and explicitly checking the return value of each database call.

    See Exceptions for more information about Exceptions in PHP.

PDO standardizes on using SQL-92 SQLSTATE error code strings; individual PDO drivers are responsible for mapping their native codes to the appropriate SQLSTATE codes. The PDO::errorCode() method returns a single SQLSTATE code. If you need more specific information about an error, PDO also offers an PDO::errorInfo() method which returns an array containing the SQLSTATE code, the driver specific error code and driver specific error string.

Example #1 Create a PDO instance and set the error mode

$user 'dbuser';
$password 'dbpass';

try {
$dbh = new PDO($dsn$user$password);
} catch (
PDOException $e) {
'Connection failed: ' $e->getMessage();



PDO::__construct() will always throw a PDOException if the connection fails regardless of which PDO::ATTR_ERRMODE is currently set. Uncaught Exceptions are fatal.

Example #2 Create a PDO instance and set the error mode from the constructor

$user 'googleguy';
$password 'googleguy';

    Using try/catch around the constructor is still valid even though we set the ERRMODE to WARNING since
    PDO::__construct will always throw a PDOException if the connection fails.
try {
$dbh = new PDO($dsn$user$password, array(PDO::ATTR_ERRMODE => PDO::ERRMODE_WARNING));
} catch (
PDOException $e) {
'Connection failed: ' $e->getMessage();

// This will cause PDO to throw an error of level E_WARNING instead of an exception (when the table doesn't exist)
$dbh->query("SELECT wrongcolumn FROM wrongtable");

위 예제의 출력:

Warning: PDO::query(): SQLSTATE[42S02]: Base table or view not found: 1146 Table 'test.wrongtable' doesn't exist in
/tmp/pdo_test.php on line 18

add a note add a note

User Contributed Notes 1 note

Praveen Raj
5 years ago
Setting the PDO::ATTR_ERRMODE to PDO::ERRMODE_EXCEPTION applies to both PDO and PDO::PDOStatement objects. Also, exceptions are thrown by: PDO::beginTransaction(), PDO::prepare(), PDOStatement::execute(), PDO::commit(), PDOStatement::fetch(),  PDOStatement::fetchAll() and so on... Some of these are specified in their respective documentations as to return 'false' in case of an error.
To Top