13

If I use @ in my code, will it affect performance?

Piskvor left the building
  • 91,498
  • 46
  • 177
  • 222
Gaurav
  • 28,447
  • 8
  • 50
  • 80
  • I've never come across a situation when I would absolutely need to use it. Have you? – Mchl Feb 02 '11 at 08:54
  • possible duplicate of [Reference - What does this symbol mean in PHP?](http://stackoverflow.com/questions/3737139/reference-what-does-this-symbol-mean-in-php) - all the questions regarding the error suppression operator linked in the reference will tell you that you should not use it. The comments on the Manual page have some comments regard performance as well. – Gordon Feb 02 '11 at 11:15

6 Answers6

24

This article is helpful for answering your question: http://anvilstudios.co.za/blog/php/how-to-ignore-errors-in-a-custom-php-error-handler/

Specifically the section "@ has its uses":

Now one really should use the @ operator very sparingly, handling errors instead of suppressing them. But there are a small number of situations I can think of where one might need to suppress some PHP errors. Let me offer two examples :

  • You could be using some large external library which has made use of the @, and so need to be able to ignore those errors as the author of the library intended, otherwise your program is going to trip up where it doesn’t need to. You could edit the library, but it might take a lot of time, and your changes would again have to be applied each time the author releases an update to the library.

  • Another example might be when the fopen function is used to open an external URL, and the URL cannot be opened for one of many possible reasons. The function returns false to indicate a fail, which is great, but to quote the PHP manual, "an error of level E_WARNING is generated" too, not so great — it should really result in an exception being thrown instead, as this is an irregular situation, but one which should be expected. In this case one would like to be able to ignore the error, and continue with the program execution, explicitly responding in an appropriate way – exactly what exceptions are for! There is, however, a way to convert the error to an exception and so avoid using the @ in this situation. In your custom error handler (which is where we find ourselves in this post), throw an ErrorException – this then requires you to explicitly catch and handle it in the code that was using the @ before, which is a better way of handling errors.

Lemmings19
  • 1,383
  • 3
  • 21
  • 34
Haim Evgi
  • 123,187
  • 45
  • 217
  • 223
  • 3
    Of two situation described there, the first one has some merit. You're stuck with poorly written library, you need to deal with it. The second one however can be solved in a more elegant manner by using custom error handler to throw `ErrorException`s, and then handling these. http://www.php.net/manual/en/class.errorexception.php – Mchl Feb 02 '11 at 08:51
  • 1
    I second this answer, especially as I wrote the [How to ignore @ errors in a custom PHP error handler](http://anvilstudios.co.za/blog/php/how-to-ignore-errors-in-a-custom-php-error-handler/) article. =) @Mchl's comment is valid, and is exactly what we do in our custom framework. I've updated the article to reflect this, thanks. – Abraham Feb 03 '11 at 10:20
8

You should not use the error suppression operator.

In a production environment, no PHP error messages should be shown to the user. They are not useful, because they are full of technical details and do not tell the user how to proceed. Instead, log the error and show your own error message.

In a development environment, all PHP error messages should be shown to the user. They are a vital clue as to the cause of the problem and should be noticed early.

Use the Errors and Logging Configuration Options to distinguish between theses two. Performance is not a useful criterion to decide whether to use @ or not.

Oswald
  • 31,254
  • 3
  • 43
  • 68
6

"A foolish consistency is the hobgoblin of little minds." :) To say "never use it" is a bit of an amateurish stance, IMO. I much prefer $var = @$_POST['key'] to $var = isset($_POST['key'])? $_POST['key'] : null;

grantwparks
  • 1,124
  • 9
  • 13
2

Yes, it does affect performance of your script in a (significant) way.

Read the article PHP Error Suppression Performance.

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
gnur
  • 4,671
  • 2
  • 20
  • 33
2

The @ itself is not the cause of performance problems (which, btw, are mostly unnoticable in profiling graphs). Missing array indicies and undefined variables cause notices/warnings and that's where a slowdown occours. The error suppression operator itself is not at fault.

Using @$var in lieu of the fugly isset($var)?$var:NULL has the advantage of still being able to log debug notices, where isset completely hides them.

mario
  • 144,265
  • 20
  • 237
  • 291
  • Actually, what error suppresion operator does is quite more than that. It stores the current error reporting level, switches error reporting to 0, executes the statement it's in front of and finally restores previous error reporting level. Quite a lot I'd say. – Mchl Feb 02 '11 at 08:57
  • 3
    @Mchl: Quite a lot, still quite insignificant. It's a micro optimization topic. Eschewing @ is as senseful as using single quotes (unless you have a billion strings or error sources in your app, of course). – mario Feb 02 '11 at 09:00
  • The point is to not have these error sources in the first place, so that you don't need to supress them ;) – Mchl Feb 02 '11 at 09:23
  • @Mchl: There's a difference between errors levels. And having more debug messages is usually advantageous. Supressing and avoiding isn't always the best method. – mario Feb 02 '11 at 09:46
  • 2
    That's what I'm saying. Write code in such a way, it raises no error messages of any level (E_ALL | E_STRICT). It's totally doable. – Mchl Feb 02 '11 at 10:58
  • 1
    @Mchl. Nope. Real errors (E_ERROR and maybe E_WARNING) should be avoided (exempt race conditions with the file API). But E_NOTICEs aren't errors. Likewise E_DEPRECATED and E_STRICT are cargo cult programming error levels, where eschewing peculiarities without making educated choices is not universally sensible. – mario Feb 02 '11 at 11:05
  • I just don't know how to respond to that... Sure you can code ignoring E_NOTICEs. Your scripts will work anyway. However coding in such a way, that your code don't raise those is 1. easy, 2. makes your code more robust, 3. helps avoid simple, yet hard to find mistakes. E_DEPRECATED: sure, you can ignore that. Worry about it when the features are actually removed from PHP and you have to revisit legacy code to fix that. I guess that's cheaper. – Mchl Feb 02 '11 at 11:18
  • 1
    @Mchl. You can also ignore E_NOTICEs by using `isset` to suppress it syntactically. But that doesn't affect the behaviour nor does it raise quality. It's a myth that "error"-free code is more robust. --You likewise overgenerilize the implications of E_DEPRECATED. For example `var = & new Xy` is obsolete and **should** be removed - but only **where unneeded**. The syntax will never be disabled, because it would break the overall language behaviour. And assigning a reference can very well still have practical purposes. Unverified relying on E_DEPRECATED notices is inadvisable. – mario Feb 02 '11 at 11:35
  • How does using isset() suppress E_NOTICE? If you mean the snippet you posted in your answer, it's a stupid example to begin with!. If you need this variable to be set, and it is not, you need to throw an exception or react otherwise. Assigning an object reference by reference? Show me where it could possibly be needed. – Mchl Feb 02 '11 at 11:37
1

Yes, it will decrease your performance when hunting for bugs. So no, you shouldn't use it unless you're sure you won't cause more problems that way.

Gareth
  • 133,157
  • 36
  • 148
  • 157