Rarst and I were debating offline about the use of the '@' error suppression operator in PHP, specifically for use to test for existence of "optional" array keys, i.e. array keys that are being used as a switch here a their lack of existence in the array is functionally equivalent to the array having the key with a value equaling false.

Here is pseudo-code for this scenario:

 function do_something( $args = array() ) {
   if ( @$args['switch'] ) {
      // Do something with this switch
   // continue on...

vs. this approach:

 function do_something( $args = array() ) {
   if ( ! empty( $args['switch'] ) && $args['switch'] ) {
      // Do something with this switch
   // continue on...

Of course in most use-cases, suppressing errors would not be A Good Thing(tm). However in this use-case where an array is passed with an optional element, it seems to me that it is actually a very good technique but I could be wrong and would like to hear other's opinions on the subject before I make up my mind.

I do know that there are alleged performance hits for using the former approach but I'd like to know how they compare with the alternative and if they performance hits really matter in real world scenarios?

P.S. I decided to post this because, after debating this offline with Rarst, he asked a more general question here on Programmers but didn't actually give a detailed example of the specific use-case we were debating. And since I'm pretty sure he'll want to use the out-of-context answers on that other question as justification for why the above is "bad" I decided I needed to get opinions on this specific use-case.

  • @Yannis - They are related, but different. The other question opened the topic up into general issues regarding use of error suppression, and this question is trying to stay focused on ONLY the one use-case. Commented Nov 17, 2011 at 22:48
  • @Yannis - The other question has already gotten several long answers that were focused on the general case, so few if any will answer the most specific question. You get too pedantic regarding "alleged"; the point was to ask if the performance hit was significant. Commented Nov 17, 2011 at 23:22
  • ps, I've upvoted as I think it is a good question and doesn't deserve the downvote it had. Commented Nov 18, 2011 at 3:38
  • why not write a function that implements the repeated pattern? Commented Nov 20, 2011 at 15:17
  • I will not write a detailed answer, but I think the approach with error suppression is a lot cleaner! We've been using it for years in our team with no negative consequences whatsoever. The important thing is that, like you pointed out, the @ operator is only used in this case and not to suppress errors in random cases and especially not with the function calls. Commented Feb 7, 2013 at 20:30

1 Answer 1


First, when talking about performance penalties, you cannot get a sensible answer unless there is context to where it is to happen.

To illustrate, is a 100ms delay to log a stackdump when a program terminates acceptable? More than likely.

Is that same 100ms delay acceptable in a tight loop that runs each time you process a record from 100 million? Of course not.

Second, how is someone to know you have suppressed the error because you are actually using it for logic-flow control as opposed to not knowing any better and just trying to implement 'See no evil'. Self-documenting code is better than needing explicit comments to assure people of your intentions.

Third, as noted by Yannis in the other question, you are really setting yourself up for failure because of the potential for unintended consequences.

So, for the sake of those poor souls that have to maintain your code in the future, just don't do it!

After all, what are you really gaining?

  • 1st - My point exactly, see my benchmark. 2nd, people will know because we would documented it as part of our coding standard for the PHP-based framework we'll be releasing. 3rd, can you explain what unintended consequences? All Yannis wrote are things that don't apply here. What I'm gaining is a lot cleaner and easier to read code (from code that is already very complex by nature), and less chance of typos or copy-paste errors. Those things are huge compared to the only legitimate downside I've seen mentioned which is a tiny performance hit. Commented Nov 18, 2011 at 0:30
  • I will say your 2nd point would be very valid if done in the context of random code, but if done in the context of a documented standard where the use-cases are clear, I don't think the concern is significant. BTW, this framework would be for WordPress designers to use (but not modify), so probably 95% of them would not even understand this debate. Commented Nov 18, 2011 at 0:52
  • If 95% of your audience doesn't understand something, isn't that a good sign not to do it? Commented Nov 18, 2011 at 1:56
  • 1
    @Mike, special cases add confusion, increase the learning curve as well as the potential for error. Especially given that this isn't adding real value, is non-standard usage, has potential performance impacts and that of the answers/votes on this and the last question all indicate people here agree it is a bad thing, perhaps it is time to realize it probably isn't the best idea? It seems you have strong personal taste preferences to this, but it seems like it is excessively clouding your judgement on this issue. Commented Nov 18, 2011 at 3:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.