Skip to content

Hide all error messages PHP

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.


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 in case 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:

@mysql_query("SELECT * FROM `anInvalidTableName`") or die("There was an error! ".mysql_error());
Code language: PHP (php)

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

For example:

if (isset($myVar) && !empty($myVar)) { // $myVar is now safe to use! }
Code language: PHP (php)

See also  How to get the Hours Difference (in HH:MM format) in PHP
Notify of
Oldest Most Voted
Inline Feedbacks
View all comments
jevin balar
9 years ago

It will better to use die()…

11 years ago

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…

11 years ago

Nice Share….(Dude)

Would love your thoughts, please comment.x