I’ve seen some confusion online lately about the purpose of the “@” operator in PHP. Let’s figure out exactly what the “at operator” does.
PHP holds your hand with error reporting during development by printing error messages to the user’s browser automatically when something goes wrong. This often looks something like this:
Warning: mysql_connect() [function.mysql-connect]: Unknown MySQL server host ‘woopsy.example.com’ (1) in errors.php on line 3
The code that created this warning looks like this:
mysql_connect( "woopsy.example.com" );
Pretty simple — I tried to connect to a non-existent MySQL server using a mistaken hostname. This is handy, but I usually don’t like these kinds of errors to show up when a user browses my site. We can make the error go away by prepending a “@” on the front of the call to mysql_connect(), like this:
@mysql_connect( "woopsy.example.com" );
This gets rid of the warning message we saw earlier, but now we have no way of knowing whether mysql_connect() was actually able to connect or not. To fix that, we need to check the return value. According to the mysql_connect() documentation, the function returns a MySQL link identifier on success and FALSE on failure. So, let’s do this:
$db = @mysql_connect( "woopsy.example.com" );
if( $db === false )
echo "Could not connect to server.";
The lesson to take away from this is that the “@” operator suppresses error messages, not return values. You can read more about the operator at the PHP Error Control Operator documentation page.
For the motivated reader, the “@” operatore has many more applications. You can use it to suppress errors in include files and even bad array indexes.
The best way to deal with errors, however, is to use your own error handling function by calling set_error_handler() . This way, you can get notified whenever an error occurs, and you can even be told the error number, message, file, and line number. This way you can log it or even present a link for users to report the bug. It’s very handy, and a great way to find and fix bugs without requiring too much user inconvenience.
The phpLDAPadmin project has an excellent implementation of an error handler, which can be viewed here. Search that page for pla_error_handler. It reports lots of versions (ie, the web server and PHP version), the exact error message, and even some PHP settings. It proved very useful for users to report bugs, since they could just copy/paste the output on the SourceForge bug tracker. ‘
This leads me to my final comment. I’ve already mentioned that the best way to handle errors in PHP is to implement your own error handler and call set_error_handler(). In this function, you should log all errors, and then only display a message for those that happen without the “@” operator present. In other words, you should do something like this:
function my_error_handler( $errno, $errstr, $file, $lineno )
my_log_msg( "Error $errno: $errstr in file $file on line $lineno" );
if( 0 == ini_get( "error_reporting" ) || 0 == error_reporting() )
// Display an error message of some kind
Any now my final comment: I use error_reporting() in all my PHP applications to set the strictest error reporting possible like so:
error_reporting( E_STRICT );
You may not want such strict error reporting in your application, so choose from the available error levels. This will give you all kinds of error messages, but it will help you bullet-proof your code in a jiffy.
Enjoy your error reporting!