1 minute read

I appreciate that to most people, this is not a new topic and it almost goes without saying, however I can understand that not everybody knows this, especially when you're just starting out with PHP.

Back in 2008, I wrote an article titled “50+ PHP optimisation tips revisited“. Although it was written for fun and to include citations for tips that had gone without any supporting evidence, the underlying issue with the article was that “premature optimization is the root of all evil”.

At the time, I had no real argument for this witty retort, however in hindsight, my reason for this was to settle those arguments of best practice, no matter how trivial, the evidence is there in black and white.

The same is true with error suppression, despite what the PHP manual does or does not say.

The use of the at sign (@), the Error Control Operator in PHP has been prevalent through it’s history.

People often use it instead of a ternary operator, for example:

$var = isset($_GET['var']) ? $_GET['var'] : ''; vs $var = @$_GET['var'];

Originally, people did begin by using this error suppression as it lead to shorter and ultimately more readable code, and nothing else mattered.

Since then we’ve learned that PHP is a bit of an odd toolbox, that doesn’t always behave as expected, so we quickly learned that suppressing errors makes debugging code exponentially more difficult.

We also learned, a long time ago, 2005 to be precise, that error suppression with @ is very slow.

There’s a lot of historic evidence to say that the @ (silence) operator gives a slow performance, but in PHP v5.4 released 1 March 2012, a fix was introduced to make it a bit faster.

So, should you use it now?

No. Absolutely not.

I can see why it might be tempting, but it’s really such a bad idea to do anything that might hinder your ability to debug a problem.

We’re now finally at the point where even well established PHP Frameworks such as CodeIgniter have decided that masking errors is a bad idea and begun to actively remove error suppression.

In conclusion, despite a leap in performance (which is still slower) hiding errors instead of logging them or catching them is a bad idea and a debugging nightmare.

Save yourself time in the long run and just don’t do it.