L'errore sta eliminando le cattive pratiche?

Penso che tu stia facendo la cosa giusta sopprimendo l'errore, perché stai implementando la tua gestione degli errori.

Potrebbe essere più semplice considerare l'equivalente, per esempio, in Java. Sopprimere l'errore usando @ è analogo a ingoiare un'eccezione. Il seguente codice, che è simile al tuo, è ragionevole:

try {
    db = new MySQLi(dbInfo);
} catch (SQLException connectionFailure) {
    die("Database error");
}

(Beh, in Java, non vorrai che il motore servlet muoia, ma ti viene l'idea.)

Tuttavia, questo non è accettabile:

try {
    db = new MySQLi(dbInfo);
} catch (Exception e) {
}

La maggior parte della soppressione degli errori di PHP viene eseguita con noncuranza, analogo al secondo esempio, quindi la reazione istintiva al codice.

La soppressione degli errori è negativa, perché non nasconde solo le informazioni che già conosci ( qualcosa è andato storto). Può anche nascondere informazioni vitali per il debug di cui non sei a conoscenza ( cosa , dove e perché ).

In questo specifico esempio, " Errore nel database " non è un ottimo messaggio di errore. Qualcosa è andato storto con il DB. Non molto illuminante. " Avviso: mysqli :: mysqli (): php_network_getaddresses: getaddrinfo non riuscito: non si conosce questo host. in alcuni \ file \ percorso sulla linea 6 "è in realtà un messaggio di errore migliore. Ti dà una posizione e una ragione per il problema. Puoi saltare direttamente dentro e avviare il debug, perché l'errore è già stato individuato.

Naturalmente, i progettisti di biblioteche hanno talvolta la tendenza a portare a molti avvertimenti irrilevanti. Non conosco abbastanza bene PHP per sapere se ha un modo per filtrare gli avvertimenti a cui non sei interessato. So che leggere uno stacktrace di cento righe non è molto illuminante. Ma la risposta corretta a troppe informazioni non è quella di ridurre la quantità di informazioni a zero , ma di filtrare le parti irrilevanti a un certo punto. L'operatore @ non ha questa granularità (il suo motto è tutto o niente ), e quindi non è uno strumento adatto per un'efficace gestione degli errori.

Ci sono alcuni casi in cui si sa che un certo errore sarà risulterà, e che la risoluzione del problema reale è più costosa del silenziamento del messaggio (e della conseguente potenziale ricaduta). Questo potrebbe essere il caso di uno script unico, ma tieni le dita nelle orecchie e " la la la " è non una risposta professionale ai (potenziali) bug .

Sopprimere gli errori è negativo perché nasconde il problema, che molte volte non siamo nemmeno a conoscenza e può portare a comportamenti imprevisti che possono rivelarsi molto costosi in alcune applicazioni critiche, ad esempio nelle applicazioni utilizzate in ambito finanziario, sanitario e di difesa domini.

Inoltre non è una buona idea avere eccezioni non gestite nel codice e mostrare all'utente i veri messaggi di errore in quanto potrebbero causare problemi di sicurezza perché i messaggi di errore di solito rivelano molto sul tuo codice, che può aiutare utenti malintenzionati e hacker per manipolare il sistema.

Quindi la buona pratica è gestire gli errori a diversi livelli, ad esempio al più alto livello, puoi gestire l'errore semplicemente registrando l'errore reale e mostrando all'utente un messaggio semplice e user-friendly.

Sì, l'errore di soppressione dell'operatore è generalmente una cattiva idea.

Dovresti gestire la segnalazione degli errori nella configurazione ( php.ini ). Quindi puoi scegliere un'impostazione diversa per ogni ambiente (ad esempio, lasciare gli avvisi in fase di sviluppo e nasconderli nella produzione).

L'unica situazione quando si utilizza @ potrebbe avere senso quando si sviluppa una libreria per altri sviluppatori. Se scegli volontariamente di fare qualcosa che produce un avvertimento e non vuoi infastidire gli utenti della tua biblioteca con un avviso che non dipende da loro, @ potrebbe essere una soluzione.

Non riesco a pensare a nessun altro uso.