views:

106

answers:

4

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.

+3  A: 

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.

code_burgar
I suspected as much, thanks. I think I'll remove them.
Evernoob
There is 1 valid use them: if you check for the return value and handle the error yourself.
Jacco
+3  A: 

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.

karim79
+2  A: 

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.

Tom Haigh
As usual it depends on where and how it's used.
VolkerK
+1  A: 

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()

Felix