PHP escaping error reporting with @

Question

I am currently refactoring some code for work and I have come across some function calls prefixed by the "@" symbol. As I understand it, this is intended to escape PHP error reporting if the call fails.

Is this type of thing good practice? I understand the rationale in a development environment but when the site is pushed to production shouldn't all errors be handled properly rather than just escaped?

The use of this symbol would therefore mean that the developer has to sort through the code at a later stage to remove all error reporting escapes.

I am unsure whether to remove these symbols and just find a better way to handle potential errors or not.

For clarity, the function this was used on was the native PHP fsockopen() function.

Answer 1

That's probably among the worst practices you can come across in php code. It basically tells the interpreter to suppress errors and just try to do whatever the code asks it to do regardless of the outcome.

A great way to drag yourself and fellow teammates into all-nighter phantom bug hunts once the app has grown substantially.

Try-catch with custom exception handling is the way to go.

Answer 2

I think it is sometimes understandable to use @ for calling functions like fsockopen(), because when they fail they will raise a warning as well as returning false.

There may be cases where you expect these calls to fail regularly and therefore do not want a warning to be raised. Obviously you shouldn't be displaying warnings in production and should be logging them instead, but you might still want to use the @ operator to stop your logs getting full. You could stop warnings getting reported at all by changing the error_reporting setting but that is not ideal.

Answer 3

That's called the error control operator , and is generally a very scary thing to consider using. A warning from the manual (the emboldening is mine):

Currently the "@" error-control operator prefix will even disable error reporting for critical errors that will terminate script execution . Among other things, this means that if you use "@" to suppress errors from a certain function and either it isn't available or has been mistyped, the script will die right there with no indication as to why .

Answer 4

Using the "@" operator is very useful when you know that the function call can fail, like, for example, the fsockopen call. Best practice is to use this only when the function you are calling often fails and is a valid case in your application. Also, you should definitely check the return value of the function after calling it:

$fp = @fsockopen($hostname, $port);
if ($fp === false) {
    // handle connection failure
}
else {
    // handle connection success
}

You should avoid two things:

1. Not checking the return value;
2. Using the "@" operator where you don't expect an error -- for example when opening a local file or sending headers. When opening a local file fails, that is an error and it should be handled properly.

Note: you might also want to look at set_error_handler()

Answer 5

if you use your custom error-handlers, the @ operator will not help you, you will always get error-events from situations where your are handling the "Warning" in your code ... like at fsockopen etc.

so you can simple suppress effectively the warning this way:

function renameWithOutExpectedAndSelfHandledErrors( ... ) {

  set_error_handler(function(){}); // deactivate all errors
  $result = rename('not existing','blafussel');
  restore_error_handler(); // restore old error-situation

  return $result;
}