Каково использование символа @ в PHP?
Я видел использование @ перед определенными функциями, например:
$fileHandle = @fopen($fileName, $writeAttributes); Какой смысл использовать этот символ?
Он подавляет сообщения об ошибках – см. « Операторы контроля ошибок» в руководстве по PHP.
Инструкции по управлению ошибками см. В руководстве:
PHP поддерживает один оператор управления ошибкой: знак at (@). При добавлении выражения в PHP любые сообщения об ошибках, которые могут быть сгенерированы этим выражением, будут игнорироваться.
Если вы задали функцию обработчика ошибок с помощью set_error_handler (), она все равно будет вызвана, но этот настраиваемый обработчик ошибок может (и должен) вызывать функцию error_reporting (), которая будет возвращать 0, когда вызову, вызвавшему ошибку, предшествовал символ @ …
Символ @ – это оператор управления ошибками (AKA – оператор «молчания» или «запирание»). Это заставляет PHP подавлять любые сообщения об ошибках (уведомление, предупреждение, фатальное и т. Д.), Генерируемое связанным выражением. Он работает точно так же, как унарный оператор. Например, он имеет приоритет и ассоциативность. Ниже приведены некоторые примеры:
@echo 1 / 0; // Generates "Parse error: syntax error, unexpected T_ECHO" since // echo is not an expression echo @(1 / 0); // Suppressed "Warning: Division by zero" @$i / 0; // Suppressed "Notice: Undefined variable: i" // Displayed "Warning: Division by zero" @($i / 0); // Suppressed "Notice: Undefined variable: i" // Suppressed "Warning: Division by zero" $c = @$_POST["a"] + @$_POST["b"]; // Suppressed "Notice: Undefined index: a" // Suppressed "Notice: Undefined index: b" $c = @foobar(); echo "Script was not terminated"; // Suppressed "Fatal error: Call to undefined function foobar()". // However, PHP did not "ignore" the error and terminated the // script because the error was "fatal". Что именно происходит, если вы используете собственный обработчик ошибок вместо стандартного обработчика ошибок PHP:
Если вы задали функцию обработчика ошибок с помощью set_error_handler (), она все равно будет вызвана, но этот настраиваемый обработчик ошибок может (и должен) вызывать функцию error_reporting (), которая будет возвращать 0, когда вызову, вызвавшему ошибку, предшествовал символ @ ,
Это проиллюстрировано в следующем примере кода:
function bad_error_handler($errno, $errstr, $errfile, $errline, $errcontext) < echo "[bad_error_handler]: $errstr"; return true; >set_error_handler("bad_error_handler"); echo @(1 / 0); // prints "[bad_error_handler]: Division by zero" Обработчик ошибок не проверял, действует ли символ @ . В руководстве предлагается следующее:
function better_error_handler($errno, $errstr, $errfile, $errline, $errcontext) < if (error_reporting() !== 0) < echo "[better_error_handler]: $errstr"; >// Take appropriate action return true; > Также обратите внимание, что, несмотря на скрытые ошибки, любой пользовательский обработчик ошибок (установленный с помощью set_error_handler ) все равно будет выполнен!
Как и раньше, некоторые ответили ранее: оператор @ подавляет все ошибки в PHP, включая уведомления, предупреждения и даже критические ошибки.
НО: Пожалуйста, действительно не используйте оператор @ вообще.
Хорошо, потому что, когда вы используете оператор @ для подавления ошибок, у вас нет никакой подсказки, где начать, когда возникает ошибка. У меня уже было «забавное» с унаследованным кодом, где некоторые разработчики часто использовали оператор @ . Особенно в таких случаях, как операции с файлами, сетевые вызовы и т. Д. Это все случаи, когда многие разработчики рекомендуют использовать оператор @ поскольку это иногда выходит за пределы области видимости при возникновении ошибки (например, API-интерфейс 3rdparty может быть недоступен и т. Д.). .).
Но в чем смысл все еще не использовать его? Давайте посмотрим с двух точек зрения:
Как разработчик: Когда используется @ , я не знаю, с чего начать. Если есть сотни или даже тысячи вызовов функций с @ ошибка может быть такой же, как и все. В этом случае нет разумной отладки. И даже если это всего лишь ошибка 3rdparty – тогда это просто отлично, и вы закончили быстро. 😉 Кроме того, лучше добавить достаточное количество подробностей в журнал ошибок, поэтому разработчики могут легко решить, если запись в журнале – это что-то, что должно быть проверено дальше, или если это просто отказ третьей стороны, который выходит за рамки разработчика.
Как пользователь: пользователям все равно, какова причина ошибки или нет. Программное обеспечение там для работы, для завершения конкретной задачи и т. Д. Им все равно, является ли это ошибкой разработчика или проблемой третьего участника. Особенно для пользователей, я настоятельно рекомендую регистрировать все ошибки, даже если они выходят за рамки. Возможно, вы заметите, что определенный API часто отключается. Что ты можешь сделать? Вы можете поговорить с партнером по API, и если они не смогут сохранить стабильность, вам, вероятно, следует искать другого партнера.
Короче: вы должны знать, что существует нечто вроде @ (знание всегда хорошее), но просто не используйте его . Многие разработчики (особенно те, которые отлаживают код от других) будут очень благодарны.
Если сбой открытия, генерируется ошибка уровня E_WARNING. Вы можете использовать @ для подавления этого предупреждения.
Предположим, что мы не использовали оператор «@», тогда наш код выглядел бы так:
$fileHandle = fopen($fileName, $writeAttributes); И что, если файл, который мы пытаемся открыть, не найден? Появится сообщение об ошибке.
Чтобы подавить сообщение об ошибке, мы используем оператор «@», например:
$fileHandle = @fopen($fileName, $writeAttributes); «@» подавляет сообщения об ошибках.
Он используется в фрагментах кода, таких как:
@file_get_contents('http://www.exaple.com'); Если домен « http://www.exaple.com » недоступен, будет отображаться ошибка, но с «@» ничего не отображается.
PHP поддерживает один оператор управления ошибкой: знак at (@) . При добавлении выражения в PHP любые сообщения об ошибках, которые могут быть сгенерированы этим выражением, будут игнорироваться.
Если вы задали функцию обработчика ошибок с помощью set_error_handler() она все равно будет вызвана, но этот настраиваемый обработчик ошибок может (и должен) вызывать error_reporting() которая будет возвращать 0 когда вызову, вызвавшему ошибку, предшествовал символ @ ,
1) @ -оператор работает только с выражениями.
2) Простое эмпирическое правило: если вы можете принять значение чего-то, вы можете добавить к нему оператор @. Например, вы можете добавить его к переменным, функциям и включить вызовы, константы и т. Д. Вы не можете добавлять его к определениям функций или классов или условным структурам, таким как if и foreach, и так далее.
Предупреждение:-
В настоящее время префикс оператора ошибки «@» даже отключает отчет об ошибках для критических ошибок, которые прекратят выполнение скриптов. Между прочим, это означает, что если вы используете «@» для подавления ошибок от определенной функции, и либо она недоступна, либо была опечатана, скрипт будет умирать прямо там без указания относительно причины.
Возможно, стоит добавить здесь несколько указателей при использовании @, о которых вы должны знать, для полного прохода вниз этот пост: http://mstd.eu/index.php/2016/06/30/php- скоропалительный-что-это-The-символ используется для-в-PHP /
- Обработчик ошибок по-прежнему запускается даже с добавленным символом @, это просто означает, что установлен уровень ошибки 0, это должно быть надлежащим образом обработано в пользовательском обработчике ошибок.
- Предоставление include с @ будет устанавливать все ошибки в файле include на уровень ошибки 0
Php символ перед функцией
@print($a);
is equivalent to
if isset($a) echo $a ;
@a++;
is equivalent to
if isset($a) $a++ ;
else $a = 1;
It’s still possible to detect when the @ operator is being used in the error handler in PHP8. Calling error_reporting() will no longer return 0 as documented, but using the @ operator does still change the return value when you call error_reporting().
My PHP error settings are set to use E_ALL, and when I call error_reporting() from the error handler of a non-suppressed error, it returns E_ALL as expected.
But when an error occurs on an expression where I tried to suppress the error with the @ operator, it returns: E_ERROR | E_PARSE | E_CORE_ERROR | E_COMPILE_ERROR | E_USER_ERROR | E_RECOVERABLE_ERROR (or the number 4437).
I didn’t want to use 4437 in my code in case it changes with different settings or future versions of PHP, so I now use:
function my_error_handler ( $err_no , $err_msg , $filename , $linenum ) if ( error_reporting () != E_ALL ) return false ; // Silenced
>
// .
>
?>
If the code needs to work with all versions of PHP, you could check that error_reporting() doesn’t equal E_ALL or 0.
And, of course, if your error_reporting settings in PHP is something other than E_ALL, you’ll have to change that to whatever setting you do use.
After some time investigating as to why I was still getting errors that were supposed to be suppressed with @ I found the following.
1. If you have set your own default error handler then the error still gets sent to the error handler regardless of the @ sign.
2. As mentioned below the @ suppression only changes the error level for that call. This is not to say that in your error handler you can check the given $errno for a value of 0 as the $errno will still refer to the TYPE(not the error level) of error e.g. E_WARNING or E_ERROR etc
3. The @ only changes the rumtime error reporting level just for that one call to 0. This means inside your custom error handler you can check the current runtime error_reporting level using error_reporting() (note that one must NOT pass any parameter to this function if you want to get the current value) and if its zero then you know that it has been suppressed.
// Custom error handler
function myErrorHandler ( $errno , $errstr , $errfile , $errline )
if ( 0 == error_reporting () ) // Error reporting is currently turned off or suppressed with @
return;
>
// Do your normal custom error reporting here
>
?>
For more info on setting a custom error handler see: http://php.net/manual/en/function.set-error-handler.php
For more info on error_reporting see: http://www.php.net/manual/en/function.error-reporting.php
Be aware that using @ is dog-slow, as PHP incurs overhead to suppressing errors in this way. It’s a trade-off between speed and convenience.
If you use the ErrorException exception to have a unified error management, I’ll advise you to test against error_reporting in the error handler, not in the exception handler as you might encounter some headaches like blank pages as error_reporting might not be transmitted to exception handler.
function exception_error_handler ( $errno , $errstr , $errfile , $errline )
throw new ErrorException ( $errstr , 0 , $errno , $errfile , $errline );
>
function catchException ( $e )
if ( error_reporting () === 0 )
return;
>
function exception_error_handler ( $errno , $errstr , $errfile , $errline )
if ( error_reporting () === 0 )
return;
>
throw new ErrorException ( $errstr , 0 , $errno , $errfile , $errline );
>
function catchException ( $e )
// Do some stuff
>
PHP. Собака — зло?
Задался вопросом, в каких случаях оправдано употребление «@» (собаки) для подавления ошибок, которая позволяет подавлять ошибки не только у операторов, но и заменять собой вызовы проверок с помощью «isset» ( if (@$_GET[‘param’]) …)
Побороть отображение ошибок можно несколькими способами. Например:
1. Оператором «@»:
$а = @(57/0);
В данном случае обходим проверку деления на ноль. Быстрое решение для ленивого кодера. Отмечу, что это быстрое решение работает немного медленнее, к тому же усложняется отладка кода.
2. Отлавливаем операторами try … catch
try catch(Exception $e)
3. Выставляем нужный уровень оповещения.
Если переменные не инициализированы (не существуют), часто выставляют нужный error_reporting и display_errors в ноль и не заморачиваются с проверками:
$b += (int)$_GET[‘отсутствующая переменная’];
if (isset($_GET[‘переменная’])) $b += (int)$_GET[‘переменная’]);
>
Как вы считаете, указывает ли использование «@» на некомпетентность программиста? Или все-таки в некоторых случаях оправдано употребление этого оператора (fopen, mysql_connect…)?
Еще хотелось бы привести в пример простую функцию, которую довольно часто применяю для проверки наличия индексов в массиве. Если элемент существует, то он возвращается функцией.
function chk($array, $i) return isset($array[$i])? $array[$i]: null;
>
Выглядит так:
if ($var = (int) chk($_GET, ‘индекс’)) $b += $var
>
А так можно заодно проверить наличие переданной переменной в массиве:
if (in_array($var = chk($_GET, ‘индекс’), array(‘hello’, ‘world’))) … переменная $var не пустая и присутствует в массиве …
>
Буду рад, если кому пригодится (: