The at sign is used to hide error messages. As far as I see, there is absolutely no use case or excuse for using it.
There are a few rare situations where it indeed makes sense to use error suppression.
One of them are atomic filesystem operations. E.g. instead of writing
if (file_exists($fileName)) {
unlink($fileName);
}
you just do
@unlink($fileName);
This makes sure that your code is not subject to race conditions.
Generally @ is useful in situations where PHP chose an inappropriate error model for a function. The above unlink function is one such example. Similarly there are other functions where PHP throws errors, even though it shouldn't (instead using return values or catchable exceptions).
In most cases you should indeed not use it. Some cases it makes sense though:
unlink()while (@ob_end_flush());There might be some other edge cases, but besides these you should really never ever supress errors.
DOMDocument, invalid HTML will throw warnings, we don't care on most cases.Mail, you'll get warnings about functions that shouldn't be called statically, that's because Mail supports PHP 4. These can be safely ignored.unlink(), you suppress errors to prevent race conditions.As with all tools available (both in programming and outside of it), everything has a legitimate use case.
The first example that comes to mind for the error suppression operator would be something like
if (!@unlink($file)) {
// I am already handling the error. I don't care what caused it.
// Even NOT handling this case at all could be a legitimate reaction
// depending on circumstances.
}
The most common place I have seen it used is for suppressing mysql errors when working with a db. Then the user checks the response instead and prints an appropriate error message.
Example
<?php
$link = @mysql_connect('localhost', 'mysql_user', 'mysql_password');
if (!$link) {
die('Could not connect: ' . mysql_error());
}
echo 'Connected successfully';
mysql_close($link);
?>
I have also seen it used when working with ftps and sftps.
But I agree with you that I find its uses limited. If one ends up in a situation where one feels the need to use the @-sign at own produced code, I think it's time to rethink the solution.
There is some value to the @ sign, but it's normally a code smell.
Consider the following: you're developing a library that needs to be compatible with multiple projects, and you don't want to change the error handler globally. Unfortunately, many PHP functions (including the sockets and streams related ones) throw a PHP error rather than an exception on failure. The "@" sign is then useful for hiding the error if and only if the error is then checked for manually and an exception is thrown if it occurred.
It's also useful for filesystem operations.
Mainly you're right though...it's normally terrible practice (: