views:

189

answers:

6

As you know, the @ characters before a php istruction suppress every eventual warning, error or notice from being raised.

Personally, i dont like this tecnique, becose i prefer to handle those errors, and in a real life, the error must no happen or have to be managed.

By the way, i find this tecnique to be applied in many scripts (cms plugins, open-source classes).

So, could the @ really be usefull (in this case, an example would be appreciated), or is just for lazy developers?

+5  A: 

Just think of, for example, a failed mysql_connect call. You may want to suppress the error message otherwise shown to the user (also showing some details you usually don't want anybody else to see) in this case.

Though the PHP warning was suppressed via the @-sign, you can perform certain actions like showing a friendly error message to the user afterwards.

However "misusing" @ for things like in the example below is definitely not a good idea:

@$undefinedVariable .= 'some text';

There are far more examples for bad use of the error-suppression sign out there than the one above, you should only use it when there is no other, better way to achieve what you want.

lamas
Never really thought of ever using @ at concatenation. Good one :P
AntonioCS
A: 

I really dislike @, but sometimes in some setups it's unavoidable.

Personally I prefer to set PHP at the config to just log errors and silently fail on production setups rather than use the @ crutch to suppress messages.

Good use: warnings. Sometimes functions throw warnings and there just isn't anything you can do without redesign, but it still works properly. @ will suppress it.

Xorlev
`there just isn't anything you can do without redesign, but it still works properly` i dont think a warning can be ignored so quick, a notice maybe, but not a warnign.
DaNieL
+3  A: 

The answer to your question is simple and direct: no, @ is useless, and in fact harmful, and should not be used. Never.

The only exception I can think about are quick "run-once" scripts, when you really don't care about code quality and correctness.

In production scripts, I'd suggest using set_error_handler that converts errors into exceptions, and try with empty catch block in rare cases when an error should be ignored:

 try {
    unlink('tempfile');
 } catch(Exception $e) {
   // i don't care
 } 
stereofrog
My previous comment didn't point it out :D ... So, how are empty catch clauses (code smell!) better than @?
Mef
What exactly is wrong with above code?
stereofrog
Wrong is a harsh word that I would not use. The point is that in my understanding, empty catch clauses are bad practice. So I wonder why you prefer one bad practice over the other ;-)
Mef
agree with mef, an empty catch clause is exactly as the @ character; Except that maybe the empty clause will be easly to edit/debug int eh future.
DaNieL
This 'except' is exactly the point. Empty 'catch' shows unambiguously what you're doing and is easy to refactor later.
stereofrog
+1  A: 

There’s one use case: If you want to test scream, a PECL extension that disables the @ operator. :)

toscho
haha. good one. very clever :)
Gordon
+1  A: 

I'm a bit late, but using @ in PHP is normally not a good idea. I'd use it only for test code and surely not for production.

A much better way of handling errors is using the set_error_handler function (http://ch.php.net/set_error_handler). If something goes wrong you can just log the error (and maybe notify the admin) and then display a custom error message to the user or you may just ignore it if it's only a notice/warning. (You're probably doing this already.)

And this is where the @ comes in handy again. If you append an @ to a command and it causes any kind of error, the error handler will be called anyway, but with the parameter 'errno' set to zero. Have a look at the list of the different values of php error levels (http://ch.php.net/manual/en/errorfunc.constants.php). None of them equals zero, so you can identify errors which occured in functions with a prepending @. You could for example use it to "flag" unimportant errors (when you don't want to abort execution, but make sure to log it anyway as it can be helpful for debugging) or use it for some other purpose.

svens
+1  A: 

The only usefull situation would be:

if you do not have access to php/apache config and the errors are displayed to the user.

Otherwise, NEVER use @... and redirect the errors (in the php/apache config) to some log system (file, database, etc.).

PS: In some official PHP documentation, you can see that instead of checking if a file exists and then deletes it, they simply @unlink it. But I do not like it: I prefer to get the error in my logs in case of issue (access rights, etc.).

Toto
mmmh, the unlink make me think.. if you have to delete a file and recreate it with the same path and name, probably is accaptable to use @ instead of checking if it exist. But, the @ would hide the error even if is a `not permitted` error, and that is bad
DaNieL