Results 1 to 5 of 5
  1. #1
    Junior Member
    Join Date
    May 2015
    Posts
    0

    The mystery of errors and exceptions

    Hi,

    since many people seem to struggle a lot with error reporting and exception handling, and since the same nonsense „solutions“ still get copied and pasted around, this is an attempt of clearing things up a bit.



    Premises


    What error reporting is supposed to do:

    • distinguish between end-users and developers
    • provide developers with detailed error reports
    • provide end-users with a short, generic error message and a 5xx status code



    What error reporting is not supposed to do

    • leak critical information (file paths, queries, your database credentials, ...)
    • irritate users with technical bug reports
    • stay silent





    Common mistakes


    Displaying internal errors generated by PHP

    This is probably the most common mistake. Outputting PHP errors makes sense during development, but on the actual website, it’s very dangerous for you and irritating for your users. The PHP error messages are meant for developers, not application users. If they pop up on your website, they help attackers with detailed information while scaring legitimate users.

    Since this often happens due to a misconfiguration, make sure to properly configure PHP as explained below.


    Displaying internal errors from subsystems

    Another common mistake is taking the error messages from, for example, MySQL and dumping them on the screen with a die() or an echo. Check this pattern, which is an all-time favorite of many bullsh*t „tutorials“ and gets copied and pasted around since PHP was invented:

  2. #2
    Junior Member
    Join Date
    May 2015
    Location
    Cuba
    Posts
    0

    The mystery of errors and exceptions

    The mystery of errors and exceptions


    Hi,

    since many people seem to struggle a lot with error reporting and exception handling, and since the same nonsense „solutions“ still get copied and pasted around, this is an attempt of clearing things up a bit.



    Premises


    What error reporting is supposed to do:

    • distinguish between end-users and developers
    • provide developers with detailed error reports
    • provide end-users with a short, generic error message and a 5xx status code



    What error reporting is not supposed to do

    • leak critical information (file paths, queries, your database credentials, ...)
    • irritate users with technical bug reports
    • stay silent





    Common mistakes


    Displaying internal errors generated by PHP

    This is probably the most common mistake. Outputting PHP errors makes sense during development, but on the actual website, it’s very dangerous for you and irritating for your users. The PHP error messages are meant for developers, not application users. If they pop up on your website, they help attackers with detailed information while scaring legitimate users.

    Since this often happens due to a misconfiguration, make sure to properly configure PHP as explained below.


    Displaying internal errors from subsystems

    Another common mistake is taking the error messages from, for example, MySQL and dumping them on the screen with a die() or an echo. Check this pattern, which is an all-time favorite of many bullsh*t „tutorials“ and gets copied and pasted around since PHP was invented:

    don’t use
    PHP Code:
    mysql_query(...) or die(mysql_error());


    There’s also an object-oriented variant:

    don’t use
    PHP Code:
    try {
    $db->query(...);
    } catch (
    PDOException $e) {
    echo
    'Query failed: ' . $e->getMessage();
    }


    What’s wrong with this is that it again displays an internal error message not meant for end-users. The message will contain critical information like the exact query or even your database credentials. But it’s actually even worse than a misconfiguration, because this mistake cannot be fixed globally. A die() is a die(), you cannot turn it off. You have to actually go through your whole code and delete those parts manually.

    So never use echo or die() to display error messages from databases or other systems.




  3. #3
    Junior Member
    Join Date
    May 2015
    Posts
    0

    The mystery of errors and exceptions

    Proper error reporting


    Configuring PHP

    Start off by opening the php.ini. Note that you cannot do the error configuration within the script, because PHP might fail before the script is even executed.

    The four most important directives are:

    • error_reporting: which errors should be displayed or logged
    • display_errors: whether or not internal error messages should be displayed on the website
    • display_startup_errors: whether or not errors within the PHP system itself should be displayed
    • log_errors: whether or not errors should be written to a log; the log can be specified with error_log


    During development, you’ll probably want to see all error messages in the browser and not log them. Do this by setting error_reporting to -1, display_errors and display_startup_errors to On and log_errorsto Off. You can also exclude specific errors using the error constants. Avoid using E_ALL. Despite its name, it doesn’t cover E_STRICT errors prior to PHP 5.4.

  4. #4
    Junior Member
    Join Date
    May 2015
    Location
    Cambodia
    Posts
    0

    The mystery of errors and exceptions

    Setting up a custom error page

    If you’re using nginx with a current PHP version (at least 5.2.4) over FastCGI, this is easy: enable fastcgi_intercept_errors and define an error_page for 500 errors.

    PHP >= 5.2.4 will automatically generate a 500 code under the following conditions: a fatal error has occured, display_errors is set to Off and no output has been sent yet. All you have to do is catch the 500 code and have nginx handle it.

  5. #5

    The mystery of errors and exceptions


Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •