Какая польза от символа @ в PHP?
Я видел использование @ перед некоторыми функциями, такими как следующее:
$fileHandle = @fopen($fileName, $writeAttributes);
Какая польза от этого символа?
11 ответов
Он подавляет сообщения об ошибках - см. " Операторы контроля ошибок" в руководстве по PHP.
Это подавляет ошибки.
См. " Операторы контроля ошибок" в руководстве:
PHP поддерживает один оператор контроля ошибок: знак at (@). При добавлении к выражению в PHP любые сообщения об ошибках, которые могут быть сгенерированы этим выражением, будут игнорироваться.
Если вы установили пользовательскую функцию обработчика ошибок с помощью set_error_handler(), то она все равно будет вызываться, но этот пользовательский обработчик ошибок может (и должен) вызывать error_reporting(), которая будет возвращать 0, когда вызову, вызвавшему ошибку, предшествовал символ @...
@ Символ - это оператор контроля ошибок (он же оператор "тишина" или "отключение"). Это заставляет 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-интерфейс 3-го участника может быть недоступен и т. д.).
Но какой смысл все еще не использовать его? Давайте посмотрим с двух точек зрения:
Как разработчик: когда @ используется, я понятия не имею, с чего начать. Если есть сотни или даже тысячи вызовов функций с @ ошибка может быть как у всех. В этом случае разумная отладка невозможна. И даже если это просто ошибка 3-го участника - тогда все в порядке, и вы сделали быстро.;-) Более того, лучше добавить достаточно подробностей в журнал ошибок, чтобы разработчики могли легко решить, является ли запись в журнале чем-то, что нужно проверять дальше, или это просто сбой третьей стороны, который выходит за рамки возможностей разработчика.
Как пользователь: пользователям абсолютно все равно, что является причиной ошибки или нет. Для них есть программное обеспечение, чтобы выполнить определенную задачу и т. Д. Их не волнует, это ошибка разработчика или проблема стороннего разработчика. Специально для пользователей я настоятельно рекомендую регистрировать все ошибки, даже если они выходят за рамки. Возможно, вы заметите, что определенный API часто отключен. Что ты можешь сделать? Вы можете поговорить со своим партнером по API, и если они не могут поддерживать его стабильность, вам, вероятно, следует поискать другого партнера.
Короче говоря: вы должны знать, что существует что-то вроде @ (знание всегда хорошо), но просто не используйте его. Многие разработчики (особенно те, кто отлаживают код от других) будут очень благодарны.
@ подавляет сообщения об ошибках.
Используется в фрагментах кода, таких как:
@file_get_contents('http://www.exaple.com');
Если домен " http://www.exaple.com/" недоступен, будет отображаться ошибка, но с @ ничего не показывается.
Предположим, что мы не использовали оператор "@", тогда наш код будет выглядеть так:
$fileHandle = fopen($fileName, $writeAttributes);
А что если файл, который мы пытаемся открыть, не найден? Это покажет сообщение об ошибке.
Для подавления сообщения об ошибке мы используем оператор "@", например:
$fileHandle = @fopen($fileName, $writeAttributes);
Если открытие не удается, генерируется ошибка уровня E_WARNING. Вы можете использовать @ для подавления этого предупреждения.
Возможно, стоит добавить здесь несколько указателей при использовании @, о которых вы должны знать, для полного ознакомления просмотрите этот пост: http://mstd.eu/index.php/2016/06/30/php- скоропалительный-что-это-The-символ используется для-в-PHP /
Обработчик ошибок по-прежнему запускается даже с добавленным символом @, это просто означает, что уровень ошибки установлен на 0, это нужно будет обрабатывать соответствующим образом в пользовательском обработчике ошибок.
При добавлении с помощью @ все ошибки во включаемом файле будут установлены на уровень ошибок 0
PHP поддерживает один оператор контроля ошибок: знак at (@), При добавлении к выражению в PHP любые сообщения об ошибках, которые могут быть сгенерированы этим выражением, будут игнорироваться.
Если вы установили пользовательский обработчик ошибок с помощью set_error_handler() тогда он все равно будет вызываться, но этот пользовательский обработчик ошибок может (и должен) вызывать error_reporting() который вернется 0 когда вызову, вызвавшему ошибку, предшествовал @,
<?php
/* Intentional file error */
$my_file = @file ('non_existent_file') or
die ("Failed opening file: error was '$php_errormsg'");
// this works for any expression, not just functions:
$value = @$cache[$key];
// will not issue a notice if the index $key doesn't exist.
?>
Заметка:-
1) @-оператор работает только с выражениями.
2) Простое правило: если вы можете взять значение чего-либо, вы можете добавить к нему оператор @. Например, вы можете добавить его к переменным, функции и включить вызовы, константы и так далее. Вы не можете добавить его к определениям функций или классов, или к условным структурам, таким как if и foreach, и так далее.
Предупреждение:-
В настоящее время префикс оператора "@" для контроля ошибок даже отключает отчеты об ошибках для критических ошибок, которые прерывают выполнение скрипта. Среди прочего, это означает, что если вы используете "@" для подавления ошибок определенной функции, и она либо недоступна, либо была напечатана с ошибкой, сценарий сразу же прекратит работу без указания причины.
@ подавляет сообщение об ошибке, выданное функцией. fopen выдает ошибку, когда файл не выходит. @ Символ заставляет выполнение перейти к следующей строке, даже если файл не существует. Мое предложение было бы не использовать это в вашей локальной среде, когда вы разрабатываете код PHP.