Comments on: @ operator is slow

By: artur ejsmont

artur ejsmont — Mon, 07 Sep 2009 08:55:14 +0000

I would say @ is bad no matter what.

Well maybe except cases where you check after the silenced call and throw exception if value is not there or something. But if call causes script to die you will never have chance to get throw it anyway.

@ is like swallowing exceptions …… baaaad idea.

Art

By: Tit Petric

Tit Petric — Mon, 22 Jun 2009 07:05:54 +0000

It’s not really bad practice if you use @ with file_get_contents($url) (in CLI mode anyway).

But keep away from this:

@include(…)

This will just, like gasper said, completely hide all errors, including parse errors, in all included files. If you ever have such a dynamic system, that the included file might not exist when you call include(), just check it with file_exists …

But definetly avoid @ in most cases (especially in loops / where you’re too lazy to use isset).

By: Jan Hančič

Jan Hančič — Sun, 21 Jun 2009 13:29:28 +0000

Like I said in the post, there are valid places to use it, providing you know what you are doing. There is always an alternative to @ and you should use that, but sometimes it’s just easier to put @ infront.
But since I’ve done this test I’ll newer use it again, because it’s just too damn slow.

By: david

david — Sun, 21 Jun 2009 13:16:56 +0000

you must never use @ in you code, if you however use it, you are a really bad coder.

By: gasper_k

gasper_k — Sun, 21 Jun 2009 11:40:11 +0000

Besides the speed issues, the problem with @ is also that it completely hides errors. Debugging an application that crashes, but doesn’t report an error, can be a nightmare. This is another one of those “let’s make it easy for the programmer” PHP things, which then come back to haunt you. We’d all be better off without @.