Handling the @ Error Control Operator

For years and years, many PHP developers have used the @ error control operator to mask errors. This was especially true when using unreliable PHP libraries with badly written code. Unfortunately, the net effect of this usage only serves to propagate bad code!

Many PHP developers are exercising wishful thinking, believing that when they use the @ operator to prevent errors from being displayed, this makes it seem as if the problem has magically gone away! Trust us when we say this: it hasn’t! In this lesson, we first examine the traditional use of the @ operator, after which we examine @ operator changes in PHP 8.

@ operator usage

Before presenting a code example, once again, it’s extremely important to emphasize that we are not promoting the usage of this mechanism! On the contrary—you should avoid this usage in every case. If an error message appears, the best solution is to fix the error, not to silence it!

In the following code example, two functions are defined. The bad() function deliberately triggers an error. The worse() function includes a file in which there is a parse error. Note that when the functions are called, the @ symbol precedes the function name, causing the error output to be suppressed. In PHP 7, there’s simply no output at all, as shown here: