Quando la @ diventa utile?

Question

Come sapete, i caratteri @ prima di un'istruzione php sopprimono ogni eventuale avviso, errore o avviso di essere sollevati.

Personalmente, non mi piace questa tecnica, perché preferisco gestire quegli errori, e nella vita reale, l'errore non deve accadere o deve essere gestito.

A proposito, trovo questa tecnica da applicare in molti script (plugin cms, classi open-source).

Quindi, la @ potrebbe essere davvero utile (in questo caso, un esempio sarebbe apprezzato), oppure è solo per sviluppatori pigri?

Answer 1

Basta pensare, ad esempio, a una chiamata non riuscita mysql_connect. Potresti voler sopprimere il messaggio di errore altrimenti mostrato all'utente (anche mostrando alcuni dettagli che di solito non vuoi che nessun altro veda) in questo caso.

Anche se l'avviso PHP è stato soppresso tramite @ -sign, è possibile eseguire determinate azioni come la visualizzazione di un messaggio di errore descrittivo all'utente in seguito.

Tuttavia "abuso" @ per cose come nell'esempio qui sotto non è sicuramente una buona idea:

@$undefinedVariable .= 'some text'; 

Ci sono molti più esempi di cattivo uso del segno dell'errore di soppressione là fuori che quello sopra , dovresti usarlo solo quando non esiste un altro modo migliore per ottenere quello che vuoi.

Answer 2

Non mi piace molto il @, ma a volte in alcune configurazioni è inevitabile.

Personalmente preferisco impostare PHP nella configurazione per registrare solo gli errori e fallire silenziosamente nelle impostazioni di produzione anziché utilizzare la stampella @ per sopprimere i messaggi.

Buon uso: avvertenze. A volte le funzioni lanciano avvertimenti e non c'è proprio nulla che tu possa fare senza riprogettazione, ma funziona comunque correttamente. @ lo sopprimerà.

Answer 3

La risposta alla tua domanda è semplice e diretta: no, @ è inutile, e di fatto dannoso, e non dovrebbe essere usato. Mai.

L'unica eccezione a cui posso pensare sono gli script "run-once" rapidi, quando davvero non ti interessa la qualità e la correttezza del codice.

Negli script di produzione, suggerirei usando set_error_handler che converte gli errori in eccezioni, e try con vuoto catch blocco in rari casi in cui un errore deve essere ignorato:

try { 
    unlink('tempfile'); 
} catch(Exception $e) { 
    // i don't care 
} 

Answer 4

C'è un caso d'uso: se si desidera testare scream, un'estensione PECL che disabilita l'operatore @. :)

Answer 5

Sono un po 'in ritardo, ma l'utilizzo di @ in PHP non è normalmente una buona idea. Lo userei solo per il codice di prova e sicuramente non per la produzione.

Un modo molto migliore di gestire gli errori è utilizzare la funzione set_error_handler (http://ch.php.net/set_error_handler). Se qualcosa va storto puoi semplicemente registrare l'errore (e magari notificarlo all'amministratore) e poi mostrare un messaggio di errore personalizzato all'utente o puoi semplicemente ignorarlo se si tratta solo di un avviso/avviso. (Probabilmente lo stai già facendo.)

Ed è qui che il @ torna utile. Se si aggiunge uno @ a un comando e si verifica un qualsiasi tipo di errore, il gestore degli errori verrà chiamato in ogni caso, ma con il parametro 'errno' impostato su zero. Dai un'occhiata all'elenco dei diversi valori dei livelli di errore php (http://ch.php.net/manual/en/errorfunc.constants.php). Nessuno di questi è uguale a zero, quindi è possibile identificare gli errori verificatisi nelle funzioni con un prepagato @. Ad esempio, potresti usarlo per "segnalare" errori non importanti (quando non vuoi interrompere l'esecuzione, ma assicurati di registrarlo comunque perché può essere utile per il debug) o usarlo per qualche altro scopo.

Answer 6

L'unica situazione utile sarebbe:

se non si ha accesso a php/apache config e gli errori vengono visualizzati per l'utente.

In caso contrario, non utilizzare MAI @... e reindirizzare gli errori (nella configurazione php/apache) in un sistema di log (file, database, ecc.).

PS: in alcuni documenti ufficiali di PHP, è possibile vedere che invece di controllare se un file esiste e quindi lo elimina, è semplicemente @unlink esso. Ma non mi piace: preferisco ricevere l'errore nei miei registri in caso di problemi (diritti di accesso, ecc.).