Wozu dient das @-Symbol in PHP?

Question

Ich habe Verwendungen gesehen von @ vor bestimmten Funktionen, wie zum Beispiel der folgenden:

$fileHandle = @fopen($fileName, $writeAttributes);

Wozu dient dieses Symbol?

Answer 1

Es unterdrückt Fehlermeldungen - siehe Fehlerkontrolloperatoren im PHP-Handbuch.

Answer 2

Sie unterdrückt Fehler.

Siehe Fehlerkontrolloperatoren im Handbuch:

PHP unterstützt einen Fehlerkontrolloperator: das at-Zeichen (@). Wenn es einem Ausdruck in PHP vorangestellt wird, werden alle Fehlermeldungen, die durch diesen Ausdruck erzeugt werden könnten, ignoriert.

Wenn Sie eine benutzerdefinierte Fehlerbehandlungsfunktion mit set_error_handler() dann wird er trotzdem aufgerufen, aber dieser benutzerdefinierte Fehlerhandler kann (und sollte) die error_reporting() der 0 zurückgibt, wenn dem Aufruf, der den Fehler ausgelöst hat, ein @... vorangestellt war.

Answer 3

El @ Symbol ist das Fehlerkontrolle Betreiber (auch bekannt als der Operator "silence" oder "shut-up"). Er sorgt dafür, dass PHP alle Fehlermeldungen (notice, warning, fatal, etc.) unterdrückt, die durch den zugehörigen Ausdruck erzeugt werden. Er funktioniert wie ein unärer Operator, d.h. er hat einen Vorrang und eine Assoziativität. Im Folgenden finden Sie einige Beispiele:

@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"

Was genau passiert, wenn Sie einen benutzerdefinierten Fehler-Handler anstelle des Standard-PHP-Fehler-Handlers verwenden?

Wenn Sie eine benutzerdefinierte Fehlerbehandlungsfunktion mit set_error_handler() gesetzt haben, wird diese immer noch aufgerufen, aber diese eigene Fehlerhandler kann (und sollte) error_reporting() aufrufen, das 0 zurückgibt, wenn dem Aufruf, der den Fehler ausgelöst hat, ein @ vorangestellt war.

Dies wird im folgenden Codebeispiel veranschaulicht:

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"

Der Fehlerhandler hat nicht geprüft, ob @ Symbol in Kraft war. Das Handbuch schlägt Folgendes vor:

function better_error_handler($errno, $errstr, $errfile, $errline, $errcontext) {
    if(error_reporting() !== 0) {
        echo "[better_error_handler]: $errstr";
    }
    // take appropriate action
    return true;
}

Answer 4

Beachten Sie auch, dass trotz des Ausblendens von Fehlern jeder benutzerdefinierte Fehlerhandler (festgelegt mit set_error_handler ) wird trotzdem ausgeführt!

Answer 5

Wie schon einige zuvor geantwortet haben: Die @ unterdrückt alle Fehler in PHP, einschließlich Hinweisen, Warnungen und sogar kritischen Fehlern.

ABER: Bitte verwenden Sie wirklich nicht die @ Operator überhaupt nicht.

Und warum?

Nun, wenn Sie die @ Operator zur Fehlerunterdrückung haben Sie überhaupt keine Ahnung, wo Sie anfangen sollen, wenn ein Fehler auftritt. Ich hatte bereits einige "Späße" mit altem Code, bei dem einige Entwickler den @ Betreiber recht häufig. Vor allem in Fällen wie Dateioperationen, Netzwerkaufrufen usw. Das sind alles Fälle, in denen viele Entwickler die Verwendung des @ Operator, da dieser manchmal außer Reichweite ist, wenn hier ein Fehler auftritt (z. B. könnte eine API eines Drittanbieters unerreichbar sein usw.).

Aber was bringt es, sie trotzdem nicht zu benutzen? Betrachten wir das Ganze einmal aus zwei Perspektiven:

Als Entwickler: Wenn @ verwendet wird, habe ich absolut keine Ahnung, wo ich anfangen soll. Wenn es Hunderte oder gar Tausende von Funktionsaufrufen mit @ der Fehler kann überall auftreten. In diesem Fall ist keine vernünftige Fehlersuche möglich. Und selbst wenn es nur ein 3rd-Party-Fehler ist - dann ist alles gut und man ist schnell fertig ;-) Außerdem ist es besser, dem Fehlerprotokoll genügend Details hinzuzufügen, so dass die Entwickler leicht entscheiden können, ob ein Protokolleintrag etwas ist, das weiter geprüft werden muss, oder ob es sich nur um einen 3rd-Party-Fehler handelt, der nicht in den Verantwortungsbereich des Entwicklers fällt.

Als Benutzer: Den Nutzern ist es völlig egal, ob der Grund für einen Fehler vorliegt oder nicht. Die Software ist für sie da, um zu arbeiten, eine bestimmte Aufgabe zu erledigen, usw. Es ist ihnen egal, ob der Entwickler schuld ist oder ob es sich um ein Problem einer dritten Partei handelt. Vor allem den Benutzern empfehle ich dringend, alle Fehler zu protokollieren, auch wenn sie außerhalb des Anwendungsbereichs liegen. Vielleicht fällt Ihnen auf, dass eine bestimmte API häufig offline ist. Was können Sie dann tun? Sie können mit Ihrem API-Partner sprechen, und wenn er nicht in der Lage ist, das System stabil zu halten, sollten Sie sich wahrscheinlich nach einem anderen Partner umsehen.

Kurz gesagt: Sie sollten wissen, dass es so etwas gibt wie @ (Wissen ist immer gut), sondern nur es nicht verwenden . Viele Entwickler (insbesondere diejenigen, die Code von anderen debuggen) werden sehr dankbar sein.