3 ms·

I'm going to completely ignore the ridiculousness of the author's claims and stick with talking about @ suppression for a moment... Not this again! I've been w

I'm going to completely ignore the ridiculousness of the author's claims and stick with talking about @ suppression for a moment... Not this again! I've been working with PHP for over 10 years and seen @ suppression used at companies in the most ridiculous ways imaginable. The most common, and I believe incorrect, way @ suppression is used is when using fopen. Why do people do it so often? Probably because it says you can do so right in the php.net manual http://us2.php.net/manual/en/function.fopen.php http://us2.php.net/manual/en/function.fopen.php and has so for years. I've really lost track of how many bugs I've come across over the years in production code that could be traced back to someone @ suppressing fopen warnings. I don't care if you read some blog where the author claims using @ suppression will give you a magical 1000% increase in performance. JUST DON'T DO IT.

Gigablah 14y ago
Another common misuse I see is suppressing notices for non-existent array elements, e.g. @$array['key'].
- mootothemax 14y ago
  Another common misuse I see is suppressing notices for non-existent array elements, e.g. @$array['key'] Oh wow, that's impressively awful, way more evil than the other common "just turn off notices in php.ini" hack.
- Sharlin 14y ago
  I don't think that's intrinsically bad. Sometimes you want getting a non-existent key to noisily break, sometimes returning null is a-okay. Many languages have maps/dictionaries with a non-throwing get() operation.
  - phpnode 14y ago
    it is really horrible, just use isset().
    - frosas 14y ago
      I've being using this trick for years instead of the ugly isset($array['key']) ? $array['key'] : null; thinking I was simply ignoring those stupid "Undefined index" notices. Now I figure out I was also hiding "Undefined variable" notices when $array was not defined and a ton of potential errors when $array is an object implementing ArrayAccess. Shame on me.
      - EvilTerran 14y ago
        Finally, an explanation for why it's a bad idea, after all these people just going "it's a misuse", "impressively awful", "really horrible"... Thanks. Note to self: grep the code at work for @. Purge.
        Gigablah 14y ago
        Yes, the main issue with using @ is that it conceals side effects and sweeps all errors under the rug -- including the ones that you may actually want to handle. Although there may be some scenarios where it's permissible, such as @unlinking temporary files when upload validation fails. It only happens in exceptional cases, the outcome is not immediately crucial, and you don't have any dependent operations. All of this is moot when you do the following though: - Set error_reporting to -1 (report ALL errors) - Register a custom error handler that converts all errors to exceptions This renders the @ operator useless (it'll throw an exception regardless). I personally prefer this since it enforces error handling discipline early on.
        EvilTerran 14y ago
        That's an interesting idea on the custom error handler, I wasn't aware that those trigger regardless of @s. I guess a lot of the trouble with @ is that it affects everything that happens temporally-within the expression, but people often use it as if it only affects everything syntactically-within it... for instance, recently I came across something like: // suppress warning for <2 results @list ($foo, $bar) = returns_a_list(...); ... which would also hide any warnings that occur in the body of returns_a_list(), despite that being neither intended nor wanted. It's a shame the only @-free solutions to many popular uses of @ (like that one) are so hideously ugly. Also that I suspect that changing @ so it only affected syntactically-contained errors would be... impractical for the PHP team, for a number of reasons.
jeltz 14y ago
I have seen @ suppression on includes, which is probably the worst abuse I have seen.
- jiggy2011 14y ago
  Yep, seen @include_once("filethatdoesallxssfiltering.php") before.

Gigablah 14y ago

Another common misuse I see is suppressing notices for non-existent array elements, e.g. @$array['key'].

mootothemax 14y ago
Another common misuse I see is suppressing notices for non-existent array elements, e.g. @$array['key'] Oh wow, that's impressively awful, way more evil than the other common "just turn off notices in php.ini" hack.
Sharlin 14y ago
I don't think that's intrinsically bad. Sometimes you want getting a non-existent key to noisily break, sometimes returning null is a-okay. Many languages have maps/dictionaries with a non-throwing get() operation.
- phpnode 14y ago
  it is really horrible, just use isset().
  - frosas 14y ago
    I've being using this trick for years instead of the ugly isset($array['key']) ? $array['key'] : null; thinking I was simply ignoring those stupid "Undefined index" notices. Now I figure out I was also hiding "Undefined variable" notices when $array was not defined and a ton of potential errors when $array is an object implementing ArrayAccess. Shame on me.
    - EvilTerran 14y ago
      Finally, an explanation for why it's a bad idea, after all these people just going "it's a misuse", "impressively awful", "really horrible"... Thanks. Note to self: grep the code at work for @. Purge.
      - Gigablah 14y ago
        Yes, the main issue with using @ is that it conceals side effects and sweeps all errors under the rug -- including the ones that you may actually want to handle. Although there may be some scenarios where it's permissible, such as @unlinking temporary files when upload validation fails. It only happens in exceptional cases, the outcome is not immediately crucial, and you don't have any dependent operations. All of this is moot when you do the following though: - Set error_reporting to -1 (report ALL errors) - Register a custom error handler that converts all errors to exceptions This renders the @ operator useless (it'll throw an exception regardless). I personally prefer this since it enforces error handling discipline early on.
        EvilTerran 14y ago
        That's an interesting idea on the custom error handler, I wasn't aware that those trigger regardless of @s. I guess a lot of the trouble with @ is that it affects everything that happens temporally-within the expression, but people often use it as if it only affects everything syntactically-within it... for instance, recently I came across something like: // suppress warning for <2 results @list ($foo, $bar) = returns_a_list(...); ... which would also hide any warnings that occur in the body of returns_a_list(), despite that being neither intended nor wanted. It's a shame the only @-free solutions to many popular uses of @ (like that one) are so hideously ugly. Also that I suspect that changing @ so it only affected syntactically-contained errors would be... impractical for the PHP team, for a number of reasons.

jeltz 14y ago

I have seen @ suppression on includes, which is probably the worst abuse I have seen.

jiggy2011 14y ago
Yep, seen @include_once("filethatdoesallxssfiltering.php") before.