Why do they say using arroba to suppress errors is bad practice?

Question

In PHP, we can suppress errors using arroba before certain expressions.

This can be seen in: What is the function of@at the beginning of PHP expressions

I already watched some Hangouts on PHP and the staff was criticizing the use of @ in PHP, for the thesis that an error should be treated, not hidden.

The problem is that some PHP functions sometimes return "unwanted messages", as in the case of unlink, which, by not finding the file to delete, sends a E_WARNING.

In that case, I always use the @.

For example:

 if (@unlink($filename)) {
     echo "Arquivo deletado com sucesso";
 }

Because with the @ error will be deleted and will only return FALSE if there is any fault. And this is explained in reply of @rray.

I have some questions about this practice:

• From a development point of view, I should use a @ arroba for cases such as the function unlink, or configure error display to hide E_WARNING, or make a file_exists (in relation to the use of unlink) before making unlink?

• Can arroba be detrimental to the performance of an application? Or discouragement regarding the use of @ exists only for the sake of good programming practice?

Answer 1

Like anything, you can use without problems as long as you know what you’re doing and have a good reason to use.

In general this syntax should not be used because people do not know all consequences of its use, but not use can lead people to do other worse things, as shown in the question.

Race condition

Checking if a file exists before doing an operation with it is worse, since between the check and the operation the file may cease to exist, or become existing. This is what we call running condition, which is precisely the attempt to do something at a time when the state may have changed.

In several cases it is correct to let the error occur and check if it occurred. There is always a mechanism that identifies this, be it a traditional exception, or an error code - even if it is just a true or false. So in such cases it is correct to use this information.

Criticism

Since PHP actually has functions that in addition to generating in code also sends information to the interpreter, and this can be presented to the user, then the use of @ is appropriate.

Perhaps some of the criticisms raised are precisely because it has to be used in some situations. These functions could very well function as they function without issuing a Warning. Others criticize that some functions do not do this. That Warning ends up being important for the programmer to know that he needs to treat. Then he treats the error and puts the @ to indicate that you are aware. This is the theory. In practice we know that programmers put the @ without proper treatment. Language cannot do miracle.

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 it is clear that indirectly its wrong use can cause problems because something expected is not happening. And indirect mistakes are worse than direct ones, they generate side effects. And anything that generates side effects should be analyzed more carefully. But most programmers don’t even understand what a expression, imagine knowing what side effects are and other things that should be basic, but are considered sophisticated.

There is no performance gain in doing this. The error cost remains the same.

There is performance loss by simply using error suppression. This may vary from version to version. But beyond the cost of error occur that would already have anyway, there is a overhead additional (test conducted by Sean Mcarthur) to treat deletion. The intermediate code generated when the @ is used gets bigger, with extra instructions of no negligible cost in various scenarios. In addition, PHP needs to access INI and temporarily modify the error display and return to the original state soon after (it looks like it’s bad anyway, but they may have improved this).

It is much better to avoid error. Not only because it is correct, but also to avoid a double overhead.

Good practice

Every good practice is thought of - not always - to prevent errors and difficulty of maintenance from happening. Good practice is knowing what you’re doing and not following ready-made recipes, do because you’ve heard.

The basic rule is never to use where you do not need, because you are hiding that is programming error anyway, and the right thing is to fix the problem. And use it where you need it only when you don’t have another solution, because that’s the way PHP figured out to warn you that it requires an error handling. In these cases it even makes sense to consider what I explained above.

We can consider him as the checked Exception poor.

Answer 2

Hiding error messages/warnings creates subtle and difficult-to-detect problems, not to mention that the use of arroba is inline, then if need remove will have to be done instruction by instruction.

Use or not at?

In the example of unlink(), and some other few, is legitimate because the function does not have a default behavior. It either returns something, or simply launches a text output.

In this situation the responsible use of the arroba is chosen, or, if possible, look for an external library to perform the task.