views:

192

answers:

6

Is there any problem using the '@' while writing the code? and what is the mechanism behind it?

+6  A: 

It suppresses error reporting so I guess it makes debugging a little harder ;-)

jldupont
dang, beat me to it. If only I hadn't travelled to the PHP website to find the link ;-)
Andy E
+3  A: 

The @ operator in PHP is an error control operator. It suppresses errors for any expression that it precedes.

The only obvious problem is that it makes your code more difficult to debug.

EDIT: Since a commenter asked... It's actually rather useful in situations where you want to make use of a variable that might not exist - such as a $_GET or $_POST variable.

if (isset($_GET['hello'] && $_GET['hello'] == "yes") {} // without @
if (@$_GET['hello'] == "yes") {} // with @

Some php functions also throw errors as well as returning false so in those situations you might want to suppress the error and check the return value instead of a try and catch.

Andy E
Why would you ever want to suppress errors from something? It's effectively equivalent to `try {` ... `} catch {}` - with an empty catch-block - which is generally considered unacceptable with no excuse (there may be an excuse if you do something in `catch`, but not with an empty block).
Pavel Minaev
Considered unacceptable by whom? There are many perfectly valid reasons for using the @ operator and I've seen them used in many open source projects including Joomla and phpBB. See my update for an example of a perfectly acceptable (and recommended by me) use of the @ operator.
Andy E
@Pavel Minaev Cause its PHP? A language with more junior Senior developers then sense. I love when people do stuff like this, because it gives me job security later when I go into contract at 4x market rate to fix it.
David
As fas as i know, every time the parser encounter the '@' operator in the code, it executes the following:1. opens the pnp.ini and turns off the display_erorr2. after the parser finishes that part of the code related to the '@' it goes back to php.ini and turns on the display_errorSo i think that this a performance issue when you have a website with a good traffic.
Ashraf Sufian
@Ashraf, the php.ini settings are in-memory, proven by the fact that if you change any setting in php.ini, php has to be restarted. Any changes to variables in memory would be very fast and the data in the file itself isn't changed at all. In fact, using the @ operator in situations where warnings are logged would be faster, because there would be no write operation to the log file.
Andy E
+5  A: 

WARNING: Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution. Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why.

karim79
+1  A: 

It can be useful if you are using an external library that triggers an error which you can safely ignore. Simple example would be a library that triggers an error when it fails to connect to an external service, if you can deduce it failed based on a return value from a function you can use the @ operator to suppress the relatively unneeded error.

I'd never use it while coding though as it makes debugging the code rather difficult if you have no errors to work with, only use it on code you know "works" but can throw the odd error you're not interested in.

Mike Anchor
A: 

Not only will it suppress errors you might need to know about, but it slows down your code regardless of whether any errors are encountered. @ works by temporarily setting the php ini setting for error reporting to 0, then back to the previous setting.

Alex JL
A: 

Using @ in ANY context is a bad idea. It is almost ok to evaluate some variable

$x = @ $somearray[$somethingelse]; # suppress E_NOTICE if array key is absent

But in any other context it's absolutely terrible. The worst is calling a function with "@" in effect - the entire function and its own subroutines would then be executed with error reporting disabled. If any of those was to throw a fatal exception, you wouldn't have a clue where or what.

PHP error handling it terrible. But using @ is worse.

Sadly there is no operator to just suppress some (e.g. just E_NOTICE and E_WARN) and not others.

MarkR