Thread: PDOException

  1. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Aug 2012
    Burb of Detroit, Michigan
    Rep Power


    It's me again, sorry I'm trying to wrap head around this and get a better grasp of the following. I have modified the secure login tutorial and I know I'm not supposed to use the die statement. What I'm trying to ask and I hope to making this clear. If you shouldn't use the die statement should you just that portion of the code blank or use some other code to replace it? If you should replace it, how would you go about doing it?

    Here's an example what I'm trying to convey? (I hope I'm making myself clear enough).

    PHP Code:
    // These two statements run the query against your database table.
    $stmt $db->prepare($query);
    $result $stmt->execute($query_params);
    PDOException $ex)
    // Note: On a production website, you should not output $ex->getMessage().
                // It may provide an attacker with helpful information about your code. 
    die("Failed to run query: " $ex->getMessage());
  2. #2
  3. No Profile Picture
    I haz teh codez!
    Devshed Frequenter (2500 - 2999 posts)

    Join Date
    Dec 2003
    Rep Power
    Well you'd probably want to log the exception to a log file, and then give the user a generic error message like "Sorry, we've run into a database problem".
    I ♥ ManiacDan & requinix

    This is a sig, and not necessarily a comment on the OP:
    Please don't be a help vampire!
  4. #3
  5. Code Monkey V. 0.9
    Devshed Regular (2000 - 2499 posts)

    Join Date
    Mar 2005
    A Land Down Under
    Rep Power
    Using die() isn't a bad thing - depending on how it's used. If you have a system that is totally reliant on that DB call, you should call die() if it fails so that nothing else tries to execute. But you should also do some logging so that you know that the error has occurred and what the actual error was before you call die(). This lets you fix whatever the problem was with it.

    Even if you don't use die() you should still do some logging/debugging. If something fails you need to know what failed, where it is, and why it failed (the error message). This shows you where your code has problems and what you need to do to fix these problems.
  6. #4
  7. --
    Devshed Expert (3500 - 3999 posts)

    Join Date
    Jul 2012
    Rep Power

    leave out the try-catch completely, it's useless.

    I'll write a short text on exceptions in the next few days, because there has been massive confusion about that topic lately.

    Some things you have to know in order to understand why certain things are bad/unnecessary and what you might do instead:

    • When you don't catch an exception, it will stop the script with a Fatal Error. Depending on how you've set up your PHP (error_reporting, display_errors, log_errors), the error message will show up on the screen or in the error log or not at all.
    • When you catch an exception merely to stop the script and display the error message, that's obviously useless, because that's what an exception will do on a development server, anyway (if you've set the above mentioned parameters correctly). Even worse: When you hard-code a die($ex->getMessage()) into your script, you no longer have control over your error handling. The message will always show up on the screen, no matter if it's you playing around on localhost or a customer visiting your site online or an evil hacker trying to gain internal information about your server. That's obviously bad. What's also bad is that you've cut off important information about the error. What's with the concrete type, the file name, the line number, the stack trace etc.?
    • It does sometimes make sense to catch an exception, but only if you actually wanna do something with it. For example, you could try to fix a database connection error by trying to connect again or by using a backup database server instead.
    • Exceptions can be handled on different levels. They "bubble up", which means if PHP doesn't find a catch in the current scope, the current function call (if there's one) will fail and pass the exception on to the scope of the function call and so on. Use this feature! Don't repeat the same try-catch block for, say, each of your 100 database queries. Instead, catch all those exceptions at a higher level. But only if you actually have a special treatment for query exceptions, otherwise just let them bubble up.
    • On the uppermost level, you can -- and should -- set up some kind of global exception handling. In case of an error, you probably want to emit a 500 status code and maybe display a message to the user (as already suggested by the previous posters). Do that by either wrapping the main script in a big try-catch block or by calling set_exception_handler() or set_error_handler().

    Do you now see why this
    PHP Code:
    try {
    } catch (
    $DBException $ex) {
    "Ain't nobody got time fo dat: " $ex->getMessage());

    pattern is bad? It's useless, it cuts off important information, and it's dangerous.

    It might make sense in E-Oreo's tutorial, but on an actual website, you certainly don't want to inform your visitors about your exact database issues.

    Instead, set up a global exception handler:
    PHP Code:

    function handle_exception($error) { 
    header('HTTP/1.1 500 Internal Server Error'); 
    "There was a technical problem. Please try again in 5 minutes.";
    error_log($error->getMessage()); // an exception consists of much more than the message, so make sure you also log the other data 


    // test it 
    throw new Exception('Oops!');
    This is only an example, it's far from perfect.

    For the time being, just leave out the try-catch and let the code fail according to your configuration.
    The 6 worst sins of security ē How to (properly) access a MySQL database with PHP

    Why canít I use certain words like "drop" as part of my Security Question answers?
    There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: "select," "delete," "update," "insert," "drop" and "null".

IMN logo majestic logo threadwatch logo seochat tools logo