Posted on

My list of PHP language features with hard-to-imagine-use-cases: #1 – The @ symbol that supresses errors

I’ll preface this post by saying that the hours spent chasing bugs after 1AM are seldom remembered fondly. So perhaps that’s causing some bias in my opinion – bear it in mind.

I’m really learning PHP as I go along, so you can imagine my suprise when at 3AM I discovered the reason I wasn’t seeing an out of memory error was because in PHP:

@<any statement></any>

is the same as an empty try/catch:

try {
   <any statement>
} catch {}</any>

From the PHP syntax docs the @ symbol means:

“When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored”

You can read all about this bad language design – particularly funny is the warning they have included!

Is typing out an empty try/catch really that hard? Most decent IDE’s will do it for you. I’m struggling to see the reason why anyone would want this functionality, but would love to hear from anyone who knows.

The problem I have with it is the lack of transparency – the more features like this in a language the more difficult it becomes to read and maintain the code. One of the things I like about Java is the simple syntax. Yes that will make a language take up more ‘lines of code’ but when your IDE is writing all the boilerplate code for you, who cares? At least you know there are no special operators or obscure syntax features that will catch developers out.

It probably has a bit to do with the static typing vs dynamic typing. IDE’s generally have a hard time writing code for you if they do not know what type of objects you are dealing with. Dynamic languages tend to be terse, and the more symbols you have, the terser your applications can become.

Moral of the story: be suspicious of any syntax you haven’t seen before in PHP – no matter how innocuous it may seem.

4 thoughts on “My list of PHP language features with hard-to-imagine-use-cases: #1 – The @ symbol that supresses errors

  1. Hi Ashley,

    I appreciate that this is a very old post, but I thought I’d throw in a clarification for the sake of other folks like me who might stumble across this. PHP wasn’t developed as an OO language so I can see how it might not have made sense to someone with a Java background.

    PHP has grown more or less organically from a simple procedural language and, apart from a very limited attempt to introduce OO constructs in PHP4, it wasn’t until PHP5 that most of the things you take for granted appeared. Older language constructs are very slow to be deprecated for reasons of backward compatibility.

    So from the viewpoint of writing a simple script on a webpage (which is PHP’s origins) being able to suppress error messages is a good thing. Of course, now we have proper exception handling and all manner of other goodies the @ is a bit vestigial.

  2. Thanks for the insightful comment Chris – it’s easy to forget PHP has a long history and evolution to it’s current state. Ironically I’ve worked with it so long now, the coding in Java feels cumbersome (safe, but cumbersome).

    Perhaps the answer is a newer differently designed scripting language like ruby, all the benefits of simplicity and a modern OO architecture.

    (according to wikipedia, both came about around the same time – who knew…)

  3. I know this is a REALLY old post, but I thought I’d point out one thing. While the usage of @ is bad, it’s not as simple as replacing usages of it with a try/catch block.

    The @ is supressing PHP error messages which are not the same as exceptions. You can register an error handler that can throw exceptions, which is what Magento does, but it’s not standard.

    Any usage of the @ should include good error checking at the very least. In reality it should prompt a mental refactoring of what you are doing.

  4. Very old indeed! But you’re right, plus I’m not so scathing of PHP these days – still prefer Java though 🙂

Comments are closed.