Jump to content

Checking the Database Connection


Recommended Posts

The Script:


$dsn = "mysql:host=localhost;dbname=2354";

$db = new PDO($dsn, "root", "");



    }catch(Exception $e){
        $error = $e->getMessage();

<!DOCTYPE html>
    <title>Database Connection with PDO</title>

<h1>Connection with PDO</h1>
        echo "<p>Connection successful.</p>";
        echo "<p>$error</p>";


I have just watched a tutorial and tried out this script. The issue is that I am getting the following notice alongside with the error message:

Notice: Undefined variable: db in C:\xampp\htdocs\oophp\pdo_test.php on line 18

SQLSTATE[HY000] [1049] Unknown database '2354'

By the way this notice does happen in the tutorial as well.


My question is: How to have this in ways, where the notice does not occur?


Link to comment
Share on other sites

You'd use isset($db) instead of checking for $db directly, because the former will not trigger any notices.


However, the whole code is rather poor and a good example of what you should not do. Catching exceptions to print the error message is not only nonsense, it's downright harmful, because anybody will see your internal database issues. Don't do that. Just leave the exception alone, then PHP will trigger the standard error procedure (as defined in the php.ini) and abort the script. No need for any checks or custom error handling.

Link to comment
Share on other sites

Consolidate your connection logic with the handling of the result of that attempt.  Don't do the testing in your mainline script - do it in the connect module.  Keep like things together.  Even better - turn that connect module into a function and then simply include it (require it) at the top and then when you need to make the connection call the function.  You could then embed the error output into the function or you could test the function return in the script and output something there instead.

Link to comment
Share on other sites

Like I said, there's no need for any testing whatsoever. If the database connection fails, there's not much you can do about it. So you let PHP go through the standard procedure for fatal errors: The error message is written to the logfile, and the script is aborted (the webserver should of course display a pretty error page).


The only reason for catching an exception is to fix the problem or go through a special error procedure for this particular issue. In any other case, just let PHP do its job.


I know it's very popular in the PHP world to clutter the code with try-catch statements or even inform the user about the specifc problem (“the database connection has failed”). This is nonsense. The default error handling procedure is much smarter than what most people implement:

  • It sends detailed error information (message, location, stack trace) to the appropriate device according to the php.ini. During development, you want the error messages directly on the screen; on a live site, you want to write them to a log file.
  • It aborts the script in case of a severe error.
  • It emits a 500 status code, allowing the webserver to serve an appropriate error page.

What's the point of overriding this procedure with a dumb echo $error_message? Now you lose a lot of important information (the message is not enough), you show internal information to the user, you keep the script running when you probably shouldn't, and you lie to the webserver by sending a 200 status code.

Link to comment
Share on other sites

This thread is more than a year old. Are you sure you have something important to add to it?

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.