Categories
error-suppression operators php

Suppress error with @ operator in PHP

77

In your opinion, is it ever valid to use the @ operator to suppress an error/warning in PHP whereas you may be handling the error?

If so, in what circumstances would you use this?

Code examples are welcome.

Edit: Note to repliers. I’m not looking to turn error reporting off, but, for example, common practice is to use

@fopen($file);

and then check afterwards… but you can get rid of the @ by doing

if (file_exists($file))
{
    fopen($file);
}
else
{
    die('File not found');
}

or similar.

I guess the question is – is there anywhere that @ HAS to be used to supress an error, that CANNOT be handled in any other manner?

2

  • 6

    Your example doesn’t work; “File not found” is not the only way fopen() can fail. Perhaps the file isn’t readable. Perhaps it’s open by another process. The error conditions are platform-dependent and anyway you might not want to spend time thinking up failure cases.

    Sep 26, 2008 at 1:45

  • see also: stackoverflow.com/questions/1087365

    – dreftymac

    Oct 11, 2011 at 17:33

27

I would suppress the error and handle it. Otherwise you may have a TOCTOU issue (Time-of-check, time-of-use. For example a file may get deleted after file_exists returns true, but before fopen).

But I wouldn’t just suppress errors to make them go away. These better be visible.

3

  • 9

    The problem with that is that you end up suppressing other errors that you didn’t predict and then spend your entire day trying to track down a bug that isn’t throwing any errors. In the rare situation of a TOCTOU issue I think it’s far better for an error to be thrown as PHP errors should not be displayed to end users anyway, but it will still allow somebody to be aware of the situation through logging of errors or displaying it if the script is running in a development environment. Error supression is the best way to hide a problem. (eg. files being deleted 🙂 )

    – Gerry

    Jun 6, 2009 at 17:09

  • 8

    This is fine, but for the love of not being hunted down and murdered, please check for the right error. I once spent way too long tracking down a database problem – I was seeing Close() failures, and nothing was working. Eventually I discovered that the genious @’d the initial connection, and the “else” check was essentially empty. Removing the @, I was immediately able to discern that the connection credentials were bad.

    Jun 11, 2009 at 16:23

  • Very good point but how do you do that? @ doesn’t let us go back and see what was suppressed as far as i know. All we need here is just handling the error and then not report it.

    – toraman

    May 14 at 10:38

27

I would suppress the error and handle it. Otherwise you may have a TOCTOU issue (Time-of-check, time-of-use. For example a file may get deleted after file_exists returns true, but before fopen).

But I wouldn’t just suppress errors to make them go away. These better be visible.

3

  • 9

    The problem with that is that you end up suppressing other errors that you didn’t predict and then spend your entire day trying to track down a bug that isn’t throwing any errors. In the rare situation of a TOCTOU issue I think it’s far better for an error to be thrown as PHP errors should not be displayed to end users anyway, but it will still allow somebody to be aware of the situation through logging of errors or displaying it if the script is running in a development environment. Error supression is the best way to hide a problem. (eg. files being deleted 🙂 )

    – Gerry

    Jun 6, 2009 at 17:09

  • 8

    This is fine, but for the love of not being hunted down and murdered, please check for the right error. I once spent way too long tracking down a database problem – I was seeing Close() failures, and nothing was working. Eventually I discovered that the genious @’d the initial connection, and the “else” check was essentially empty. Removing the @, I was immediately able to discern that the connection credentials were bad.

    Jun 11, 2009 at 16:23

  • Very good point but how do you do that? @ doesn’t let us go back and see what was suppressed as far as i know. All we need here is just handling the error and then not report it.

    – toraman

    May 14 at 10:38

24

Yes suppression makes sense.

For example, the fopen() command returns FALSE if the file cannot be opened. That’s fine, but it also produces a PHP warning message. Often you don’t want the warning — you’ll check for FALSE yourself.

In fact the PHP manual specifically suggests using @ in this case!

8

  • 3

    but, surely, this can be avoided by checking file_exists($file) first?

    – Mez

    Sep 26, 2008 at 1:03

  • 15

    No it can’t, there are other failure conditions such as “no permissions to read” or “file busy.”

    Sep 26, 2008 at 1:46

  • 3

    That’s great until fopen throws an error you weren’t anticipating. You can’t check for all of your known error conditions? Create an fopen wrapper function.

    – Gerry

    Jan 28, 2012 at 4:49

  • I was tempted to plus you 1 just because you are Jason Cohen. Great answer/comment.

    Feb 22, 2013 at 14:57


  • @JasonCohen What about secure.php.net/is_readable? There is still a race condition however…

    – John M.

    Nov 3, 2015 at 23:50