It is a common practice for developers to silence errors when developing with PHP. Many times the @
operator is used to simply ignore errors and continue to work in case of failure.
PHP warnings
Here is some code that will produce warnings:
$array = array("one"=>"apple","two"=>"orange");
echo $array["three"]; // this line will print that the index is not defined;
$value = $_GET["non_existant_parameter"]; // undefined index
$value = $_GET[defined_parameter]; // undefined constant, php will assume it is a string
mysql_connect("..."); // deprecated function.
All these lines will produce warnings, but they can easily be muted with the @
operator and the code will work just fine.
I always say that it's the final product that matters. If the warnings can be turned off and the user never have to see them, then we are good. Unfortunately that's not the only problem. Having a bunch of warnings on your page, even if they are invisible takes a performance toll on your server. Here are a few benchmark that were nicely summed up on stackoverflow:
- 10k notices, with
error_reporting
anddisplay_errors
enabled : 5,162.76 ms- same, but with
display_errors
disabled : 136.18 ms- same, but with
error_reporting
disabled too : 117.79 ms- and, finally, after patching the code so it doesn't produce any notice anymore : 19.51 ms
This is insane. You gain a 265% performance boost by avoiding code that produce warnings. Here is what happens internally when you generate a warning error:
Whenever PHP generates an error message internally, it's processed and formatted all the way up to the fully formatted message that can be outputted straight to the browser. Only just before it is displayed the
error_reporting
setting is checked. This however, is not related to the @-operator exclusively. The error message is just always fully formatted beforeerror_reporting
is checked ordisplay_errors
for that matter.
Performance only is a good enough reason for fixing all your errors. Here are a few things you can do to make sure you don't generate errors.
- Make sure errors are always on in your development machine. Use
ini_set("display_errors","on");
orerror_reporting(-1);
- Make sure your variables are defined or initialized before you use them;
- Make sure your you check if an array index is set before using it:
$value = isset($_GET['param'])?$_GET['param']:false;
- Make sure your variable is an array before using it in a foreach loop. You can use the is_array() function for that.
- Upgrade your deprecated functions. They are deprecated for a good reason.
- Treat warnings like Fatal Errors.
If you only follow the first bullet point, you are on your way to fix all your errors.
There is another advantage to removing all your PHP warnings. If you are using a server error logs, chances are all the errors you are silencing are getting written right in this file. Having a server error logs with millions of lines of code is a pain in ass to debug when there is a problem. I recently had to go through all the errors log to find a code execution script that a hacker placed for more then 3 years on a website. If there were no warnings, it would be so easy to find it.
Error generated by a hack buried in over 200k lines of warning errors.
So clearing up your warnings clears up your logs to only show serious errors that need to be address, thus making debugging easier.
Comments
There are no comments added yet.
Let's hear your thoughts