Why do you say that using @ atus to suppress errors is a bad practice?


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

This can be seen at: #

I've seen some hangouts on PHP and staff were criticizing the use of @ in PHP, for the thesis that an error should be handled, not hidden.

The problem is that some PHP functions sometimes return unwanted messages, such as unlink , which, when it does not find the file to delete, issues a E_WARNING .

In this case, I always use @ .

For example:

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

Because with @ the error will be suppressed and will only return FALSE in case of a failure. And this is explained in response from @ rray .

I have some questions to ask about this practice:

  • From a development point of view, I should use @ at instances like unlink function, or set error display to hide E_WARNING , or make file_exists to unlink ) before doing unlink ?

  • Can at sign-up be harmful to an application's performance? Or does not the discouragement of using @ exist only for good programming practices?

asked by anonymous 03.09.2015 / 17:17

2 answers


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.


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.

03.09.2015 / 17:40

Hide error messages / warnings creates subtle problems that are difficult to detect, not counting the use of the inline , so if you need to remove it,

Use or not at?

In the example of unlink() , and some other , it is legitimate because the function does not have a default behavior. Now it returns something, sometimes it just throws a text output.

In this situation you choose the responsible use of the at sign, or, if possible, look for an external library to accomplish the task.

03.09.2015 / 17:36