Ho visto usi di @
fronte a determinate funzioni, come le seguenti:
$fileHandle = @fopen($fileName, $writeAttributes);
A che serve questo simbolo?
Ho visto usi di @
fronte a determinate funzioni, come le seguenti:
$fileHandle = @fopen($fileName, $writeAttributes);
A che serve questo simbolo?
Risposte:
Sopprime i messaggi di errore - vedi Operatori di controllo errori nel manuale di PHP.
isset()
superfluo l ' uso al fine di evitare undefined offset
errori.
Sopprime gli errori.
Vedere Operatori di controllo errori nel manuale:
PHP supporta un operatore di controllo degli errori: il segno at (@). Se anteposto a un'espressione in PHP, tutti i messaggi di errore che potrebbero essere generati da quell'espressione verranno ignorati.
Se hai impostato una funzione del gestore errori personalizzata con set_error_handler () , verrà comunque chiamata, ma questo gestore errori personalizzato può (e dovrebbe) chiamare error_reporting () che restituirà 0 quando la chiamata che ha causato l'errore è stata preceduta da un @ ...
Il @
simbolo è l' operatore di controllo degli errori (ovvero l' operatore "silenzio" o "arresto"). Fa in modo che PHP elimini qualsiasi messaggio di errore (avviso, avviso, fatale, ecc.) Generato dall'espressione associata. Funziona proprio come un operatore unario, ad esempio, ha una precedenza e associatività. Di seguito sono riportati alcuni esempi:
@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"
Cosa succede esattamente se si utilizza un gestore di errori personalizzato anziché il gestore di errori PHP standard:
Se hai impostato una funzione del gestore errori personalizzata con set_error_handler (), verrà comunque chiamata, ma questo gestore errori personalizzato può (e dovrebbe) chiamare error_reporting () che restituirà 0 quando la chiamata che ha causato l'errore è stata preceduta da un @ .
Questo è illustrato nel seguente esempio di codice:
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"
Il gestore degli errori non ha verificato se il @
simbolo era attivo. Il manuale suggerisce quanto segue:
function better_error_handler($errno, $errstr, $errfile, $errline, $errcontext) {
if(error_reporting() !== 0) {
echo "[better_error_handler]: $errstr";
}
// take appropriate action
return true;
}
Come già alcuni hanno risposto in precedenza: l' @
operatore elimina tutti gli errori in PHP, inclusi avvisi, avvertenze e persino errori critici.
MA: Per favore, davvero non usare affatto l' @
operatore.
Perché?
Bene, perché quando si utilizza l' @
operatore per la soppressione degli errori, non si ha idea di dove iniziare quando si verifica un errore. Mi sono già divertito un po 'con il codice legacy in cui alcuni sviluppatori hanno usato l' @
operatore abbastanza spesso. Soprattutto in casi come operazioni sui file, chiamate di rete, ecc. Questi sono tutti casi in cui molti sviluppatori raccomandano l'uso di@
dell'operatore in quanto questo a volte è fuori portata quando si verifica un errore qui (ad esempio un'API di terze parti potrebbe essere irraggiungibile, ecc. ).
Ma qual è il punto di non usarlo ancora? Diamo uno sguardo da due prospettive:
Come sviluppatore: quando@
viene utilizzato, non ho assolutamente idea da dove iniziare. Se ci sono centinaia o addirittura migliaia di chiamate di funzione con@
l'errore potrebbe essere come ovunque. In questo caso non è possibile eseguire il debug ragionevole. E anche se si tratta solo di un errore di terze parti, allora va bene e il gioco è fatto in fretta. ;-) Inoltre, è meglio aggiungere dettagli sufficienti al registro degli errori, in modo che gli sviluppatori siano in grado di decidere facilmente se una voce di registro è qualcosa che deve essere verificato ulteriormente o se si tratta solo di un errore di terze parti che non rientra nell'ambito dello sviluppatore.
Come utente: utenti non interessa affatto quale sia la ragione di un errore o meno. Il software è lì per loro di funzionare, per completare un compito specifico, ecc. A loro non importa se è colpa dello sviluppatore o un problema di terze parti. Soprattutto per gli utenti, consiglio vivamente di registrare tutti gli errori, anche se non rientrano nell'ambito. Forse noterai che un'API specifica non è in linea frequentemente. Cosa sai fare? Puoi parlare con il tuo partner API e se non sono in grado di mantenerlo stabile, probabilmente dovresti cercare un altro partner.
In breve: dovresti sapere che esiste qualcosa del tipo @
(la conoscenza è sempre buona), ma non usarla . Molti sviluppatori (specialmente quelli che eseguono il debug del codice da altri) saranno molto grati.
@
è la cosa giusta da fare sì, questo è particolarmente utile soprattutto se non stai tornando text/html
(o simile) al client. (forse ritornando image/png
o "json")
if( session_status() == PHP_SESSION_NONE ) session_start();
È un'app legacy che ho ereditato e ci sono luoghi in cui lo script di installazione viene chiamato più volte, quindi devo testarlo. Quale eventuale problema ci sarebbe nel semplice utilizzo @session_start();
?
@$this->stats['device_os'][$date][$creative_id][$device_id][$operating_system]['clicks']++;
è molto meglio dell'alternativa di avere controlli isset per ogni livello e compilarlo quando non lo è.
Supponiamo di non aver usato l'operatore "@", quindi il nostro codice sarebbe simile al seguente:
$fileHandle = fopen($fileName, $writeAttributes);
E se il file che stiamo tentando di aprire non viene trovato? Mostrerà un messaggio di errore.
Per sopprimere il messaggio di errore stiamo usando l'operatore "@" come:
$fileHandle = @fopen($fileName, $writeAttributes);
@
soluzione alternativa in primo luogo. Altri linguaggi di programmazione hanno uniforme gestione delle eccezioni per affrontare questo tipo di scenario stackoverflow.com/questions/1087365
Se l'apertura non riesce, viene generato un errore di livello E_WARNING. È possibile utilizzare @ per sopprimere questo avviso.
@
sopprime i messaggi di errore.
Viene utilizzato nei frammenti di codice come:
@file_get_contents('http://www.exaple.com');
Se il dominio " http://www.exaple.com " non è accessibile, verrà visualizzato un errore, ma con @
nulla non verrà mostrato.
PHP supporta un operatore di controllo degli errori: il segno at (@)
. Se anteposto a un'espressione in PHP, tutti i messaggi di errore che potrebbero essere generati da quell'espressione verranno ignorati.
Se hai impostato una funzione del gestore degli errori personalizzata con set_error_handler()
, verrà comunque chiamata, ma questo gestore degli errori personalizzati può (e dovrebbe) chiamare il error_reporting()
quale tornerà 0
quando la chiamata che ha innescato l'errore è stata preceduta da un @
.
<?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.
?>
Nota:-
1) L'operatore @ funziona solo sulle espressioni.
2) Una semplice regola empirica è: se puoi prendere il valore di qualcosa, puoi anteporre l'operatore @ ad esso. Ad esempio, è possibile anteporre a variabili, funzioni e includere chiamate, costanti e così via. Non è possibile anteporre a definizioni di funzioni o classi o strutture condizionali come if e foreach e così via.
Avvertimento:-
Attualmente il prefisso dell'operatore "@" per il controllo degli errori disabilita persino la segnalazione degli errori critici che interromperanno l'esecuzione dello script. Tra le altre cose, ciò significa che se si utilizza "@" per sopprimere gli errori da una determinata funzione e non è disponibile o è stato digitato in modo errato, lo script morirà lì senza alcuna indicazione sul perché.
Potrebbe valere la pena aggiungere qui ci sono alcuni suggerimenti quando si utilizza @ dovresti essere a conoscenza, per una panoramica completa guarda questo post: http://mstd.eu/index.php/2016/06/30/php- fuoco rapido-cosa-è-il-simbolo-usato-per-in-php /
Il gestore errori viene ancora attivato anche con il simbolo @ anteposto, significa solo che è impostato un livello di errore pari a 0, che dovrà essere gestito in modo appropriato in un gestore errori personalizzato.
Se si prepara un'inclusione con @, tutti gli errori nel file di inclusione verranno impostati su un livello di errore pari a 0
@
sopprime il messaggio di errore generato dalla funzione. fopen
genera un errore quando il file non viene chiuso. @
il simbolo rende l'esecuzione per passare alla riga successiva anche se il file non esiste. Il mio suggerimento sarebbe di non usarlo nel tuo ambiente locale quando sviluppi un codice PHP.