PHP Error messages showing up in your web applications are a dangerous thing. Not only does it look unprofessional, but it is also a serious security concern!

Once you have completed debugging your website or web application you can place the following one liner at the beginning of your code, this will turn off error reporting and therefore make sure that no application details are spilled to your users.

[code lang=”php”]
error_reporting(0);
[/code]

If a single line of code is causing the problems it is safer to use the at symbol (@) to suppress any errors it may cause.
You can also use “or die()” to stop the execution of your code after the suppressed error incase the remainder of your code relies on that function to return a value.
In the example below we will use the “@” and “or die” to handle everything:

[code lang=”php”]
@mysql_query(“SELECT * FROM `anInvalidTableName`”) or die(“There was an error! “.mysql_error());
[/code]

It is also good practise to make sure that all variables are set and are not empty before trying to access them.

For example:

[code lang=”php”]
if (isset($myVar) && !empty($myVar)) {
// $myVar is now safe to use!
}
[/code]

Categories: ContentGeneral

4 Comments

jevin balar · February 3, 2013 at 05:47

It will better to use die()…

Kevin · July 29, 2011 at 19:58

It’s very bad practice to use “error_reporting(0)”.

One: you’re taking the control of error reporting level away from the webserver. To update the error reporting level, you have to publish a code change. Also, if you control this at the webservice level, you can have different settings on different environments (local, test, staging, production). You can define values for ‘error_reporting’, ‘display_errors’, and ‘error_log’ in either ‘php.ini’ or in your webserver configuration (within the tag for apache, using ‘php_value display_errors Off’).

Two: what if errors are occurring? You’ll never know unless you log your errors and are checking them. You’ll especially want to know on your testing or staging environments — in these cases it’s good to have the errors shown, or at least to know that an error occurred (so you can check logs).

What’s better than suppressing errors? Setting up custom error handling. Look into ‘set_error_handler()’ and ‘set_exception_handler()’. This way you can make a decision based on the current environment. In most cases, you might just display a “pretty” error page that says “An error occurred. Please try again later.” while on the back-end logging that error for later evaluation.

I’d suggest looking here instead of just suppressing errors…

0ludonh4ck3r · June 16, 2011 at 17:46

Nice Share….(Dude)

    Andrew · June 16, 2011 at 21:12

    No problem…(Dude)

Leave a Reply

Your email address will not be published. Required fields are marked *