PHP providing error messages with @
I am currently refactoring some code to work and I came across some function calls prefixed with "@". As I understand it, this is intended to avoid PHP error messages if the call fails.
Is this type of good practice? I understand the rationale in a development environment, but when a site is redirected to production aren't all errors handled properly and not just escaped?
Thus, the use of this character means that the developer must do the sorting of the code at a later stage in order to remove all escaped error messages.
I'm not sure if to remove these symbols and just find a better way to deal with potential errors or not.
For clarity, the function it was used for was a PHP built-in function fsockopen()
.
source to share
Probably among the worst methods you can come across in PHP code. It basically tells the interpreter to suppress errors and just tries to do what the code asks it to do regardless of the result.
A great way to drag yourself and other teammates on all sorts of phantom bug hunts after the app has grown substantially.
Trying with custom exception handling is the way to go.
source to share
I think it is sometimes understandable to use @ to call functions like fsockopen (), because when they fail they will raise a warning and also return false.
There might be times when you expect these calls to fail regularly and therefore don't want an alert raised. Obviously, you shouldn't display warnings during production and should log them instead, but you can still use the @ operator to stop the logs from filling up. You can stop receiving warnings altogether by changing the error_reporting parameter, but this is not ideal.
source to share
This is called an error control statement and is usually a very scary thing to consider. Warning from the manual (my boldness):
Currently error control "@" operator prefix will even disable error reporting for critical errors , which will terminate the script execution . In particular, this means that if you use "@" to suppress errors with a certain function, and either it is not available or erroneous, the script will die right there without specifying why .
source to share
Using the @ operator is very useful if you know that a function call might fail, such as a call fsockopen
. The best practice is to only use this when a function you often call 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
}
There are two things you should avoid:
- Do not check the return value;
- Using the @ operator where you don't expect an error — for example, when opening a local file or sending headers. It fails when opening the local file, which is an error and should be handled properly.
Note: you can also look at set_error_handler ()
source to share
if you are using your custom error handlers the @ operator will not help you, you will always receive error events from situations where you handle "Warning" in your code ... for example in fsockopen
etc.
so that you can just effectively suppress the warning in 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;
}
source to share