Like anything, you can use it smoothly as long as you know what you're doing and have a good reason to use it.
In general this syntax should not be used, because people do not know all consequences of its use. But not using it can lead people to do other things worse, as shown in the question.
Race condition
Verifying that a file exists before performing an operation on it is worse, since between verification and operation the file may no longer exist, or exist. This is what is called race condition , which is precisely the attempt to do something at a time when the state may have changed.
In many cases the correct thing is to let the error occur and verify that it has occurred. There is always a mechanism that identifies this, whether it is a traditional exception, or an error code - even if it is just a true or false . So in cases like this the correct thing is to use this information.
Reviews
As PHP actually has functions that in addition to generate in code also issues information to the interpreter, and this can be presented to the user, there the use of @ is appropriate.
Perhaps some of the criticisms put forward are precisely because it has the mandatory use in some situations. These functions could very well work as they do without issuing a warning . Others criticize that some functions do not do this. This warning ends up being important for the programmer to know what he needs to handle. Then it handles the error and places @ to indicate that it is aware. This is the theory. In practice we know that programmers put @ without doing proper treatment. Language can not work miracles.
No language can protect itself from bad programmer. PHP could have a better mechanism, be more consistent, but you can always program wrong.
Performance and Errors
It does not cause direct errors. But of course indirectly its misuse can cause errors because something expected is not happening. And indirect errors are worse than direct ones, they generate side effects. And anything that bears side effects should be looked at more carefully. But most programmers do not even understand what an expression is, imagine knowing what is side effect and other things that should be basic, but are considered sophisticated.
There is no gain in performance in doing this. The cost of the error remains the same.
There is loss of performance simply by using error suppression. This may vary from version to version. But besides the cost of the error occurring that would already have anyway, there is an additional overhead ( test performed by Sean McArthur ) to treat suppression. The intermediate code generated when @ is used gets larger, with extra cost instructions nothing scant in several scenarios. In addition PHP needs to access the INI and temporarily change the error display and return to the original state soon after (it looks bad anyway, but may have improved this).
It's much better to avoid the error. Not only because it is correct, but also to avoid a double overhead .
Good practice
Every good practice is thought - not always enough - to keep errors and maintenance difficulties from happening. Good practice is knowing what you are doing and not following ready recipes, to do because you have heard.
The basic rule is to never use where you do not need to, because you are hiding it is the same programming error, and the right thing is to fix the problem. And use where you need it only when you have no other solution, because it's the way PHP has arranged to warn you that it requires an error handling. In these cases it makes even some sense to consider what I explained above.
We may consider this as poor
poor exception.
