
Five reasons why the PHP silence operator @ should be avoided - ck2
http://www.phpvikinger.org/five-reasons-why-the-shutop-operator-should-be-avoided.html
======
VMG
_Whenever the @-operator is used, PHP needs to invoke the INI settings
mechanism to change the temporary value of the error_reporting setting to 0._

Can't make this stuff up.

~~~
TazeTSchnitzel
Oh, it's just one of thousands of nonsensical PHP features.

Like the fact that the language's grammar is used to do primitive type
checking, meaning some combinations of accessors cause errors.

Or the fact the mail sending function doesn't work if one of the lines in the
email begins with a period, but only if you're on Windows.

~~~
acabal
Some of the weirder OS-specific function behaviors can be a rationalized a
little better if you view PHP functions not as sane, complete library
functions, but rather as thin wrappers to the underlying OS. For mail() it
basically just wraps the system's mail program in Linux (which comes with a
huge number of dangerous gotchas for the uninitiated) and I imagine in Windows
it wraps the local mail program which seems to have a gotcha with periods. I
think a lot of the file management functions are the same.

That's one of the many problems with PHP's underlying design philosopy:
instead of providing a higher-level interface that stays consistent across
platforms, it exposes low-level OS gunk and gotchas through its thin wrappers
on low-level-ish functions. I put together phpbestpractices.org a few months
ago in an attempt to document some of those common gotchas and provide sane
alternatives.

~~~
TazeTSchnitzel
>PHP functions not as sane, complete library functions, but rather as thin
wrappers to the underlying OS.

Except they're not really that thin.

>in Windows it wraps the local mail program which seems to have a gotcha with
periods

Nope, in Windows it implements the SMTP protocol, on UNIX it runs sendmail.

>instead of providing a higher-level interface that stays consistent across
platforms, it exposes low-level OS gunk and gotchas through its thin wrappers
on low-level-ish functions.

Except it doesn't. There's quite a few things that are _named_ like OS
functions, but are implemented internally. For example, all the C stdlib-like
string functions.

~~~
acabal
My mistake then :) I admit I haven't read the source, I'm just going off of
the quirkiness of cross-platform PHP and the way the functions seem to behave.

------
ck2
Something I found in response to:
<http://news.ycombinator.com/item?id=5036240>

The opcode examination is particularly damning.

I would like to see what PHP 5.4 generates though, the changelog states

    
    
       - Improved Zend Engine, performance tweaks and optimizations: (Dmitry)
           Improved performance of @ (silence) operator
    
    

Aha! Found the revision:
[http://svn.php.net/viewvc?view=revision&revision=302442](http://svn.php.net/viewvc?view=revision&revision=302442)

------
juan_juarez
It's interesting to find out just how many ways @ is bad but this article is
going to fall on deaf ears. The people that can be convinced that it's bad are
already not using it. Those that need to be told why the "ignore broken things
and keep on trucking" operator is bad, aren't paying attention anyways.

~~~
maratd
There are cases where you want something silenced. In my code base, there is
one place where it is used and I need it there.

I frequently use file_get_contents to retrieve data stored on external
servers. If there is a network error or the external service goes down
temporarily, it will trigger an error. I don't want my log files flooded with
transient error messages that are outside of my control. Instead, I just want
it to try again. @ makes this possible.

~~~
pavel_lishin
We opt to use the curl functions for that.

~~~
maratd
I understand that decision, but I actively try to remove any extensions that I
can do without to keep the PHP binary slim and even more reliable. My personal
way of doing things, that's all. file_get_contents can do everything the curl
extensions can, provided that you use the context options, so I just use that
and remove curl when I compile the PHP binary.

------
CWIZO
I wrote about @ and it's slowness a while back, if anyone is interested:
<http://hancic.info/at-operator-is-slow>

------
cfinke
One reason to use it: to silence functions that generate warnings when the
falsy return value would suffice.

<http://php.net/manual/en/function.parse-url.php>

 _5.3.3 Removed the E_WARNING that was emitted when URL parsing failed._

~~~
josephscott
A logical first step would be to fix all of those functions in PHP that end up
requiring the use of @. Once that is done then we could move forward with
removing all @ use.

~~~
juan_juarez
Next step, remove all PHP use.

------
artemgoutsoul
Some negative comments about the @-operator seem to be very religious. It's
just a tool that one can use for good or for evil. Many of the reasons not to
use @ described are valid, but there are cases when it makes much cleaner
code. E.g. instead of doing: if (array_key_exists($key, $a) && $a[$key] ==
$value) dostuff(); you can do: if (@$a[$key] == $value) dostuff(); This works
really well when you don't care whether $a[$key]is present or not, and when
you care only whether it contains a certain $value. In complex comparisons the
code readability difference is huge!

------
jiggy2011
One reason you might actually want to silence a warning.

You might be developing an application that functions in some P2P type fashion
or is specifically intended to be used in situations where network access will
be intermittent (on a boat perhaps?).

In such a case a mysql_connect call may have a high chance of failing and your
application is designed in such a way as to assume that this is likely (i.e
working with the return code). In such a case failing the connection is not an
error but expected behaviour.

~~~
pekk
This flags a design flaw, perhaps in mysql_connect. If a warning is trivial
enough that it's reasonable to silence, it shouldn't exist. Otherwise, it's
not reasonable to silence it!

I find it hard to believe that this is actually considered acceptable.

~~~
jiggy2011
Surely that depends on your application, in 99.9% of cases where you are using
LAMP to host some site a failed mysql_connect is probably an epic fail
condition.

My point is rather that there may certainly be applications where this is not
the case.

This is an area where exceptions are better than dumb warnings.

~~~
astrodust
Using mysql_query is an epic fail condition. Period.

------
ecaron
The guys at Smarty did some pretty good analysis on the @ operator -
specifically in cases where implementing it improved performance:
[http://blog.rodneyrehm.de/archives/12-Improving-Disk-IO-
in-P...](http://blog.rodneyrehm.de/archives/12-Improving-Disk-IO-in-PHP-
Apps.html)

~~~
ck2
Well it comes down to deciding on avoiding race conditions vs bad opcode
generation, I guess.

Maybe the solution is to use php 5.4 if it makes better silence code but I am
having a hard time letting go of suhosin.

~~~
X-Istence
Yeah ... not having SuHoSin for PHP 5.4 means I haven't deployed it yet. I
want to upgrade, but I like the extra security SuHoSin gives me.

~~~
ck2
I fear it's never coming for 5.4, Stefan Esser seems to have moved onto ios
security.

------
jasonlotito
There is a reason scream exists in xdebug. There is a reason it's called
scream.

------
parf73
@operator is much faster in 5.4.x

$x = @$f["x"] is right place to use it.

$x = @custom_func() - is a disaster, do not do it

~~~
jtreminio
> $x = @$f["x"] is right place to use it.

No, it's not. There's built-in methods for that: isset() and empty().

~~~
pavel_lishin
empty() is not a good idea. What if $f["x"] is an empty string ""? Or 0, or
0.0, or "0", or any of the other values for which it returns true?

~~~
jtreminio
It completely depends on the use case. My point was, don't use @

------
PaulAJ
Reason 6: its part of PHP.

