Questo non è specifico per PHP, quindi risponderò al caso generale.
Ci sono due tipi di errori nelle applicazioni web:
-
Script non inizializzato. Esempi: impossibile connettersi al database; file di intestazione richiesto non trovato; altro errore fatale.
-
Script inizializzato, ma c'è una condizione di errore nella logica aziendale. Esempi: l'utente inserisce la password errata.
Nel primo caso non c'è molto che puoi fare per gestire l'errore se non quello di inserire una pagina bianca generica che dice "mi dispiace, il sito è rotto". Nel secondo caso puoi facilmente intercettare l'errore e generare qualcosa di significativo per l'utente, anche se è "mi dispiace, non posso farlo, prova qualcos'altro."
Se non è possibile continuare l'elaborazione a causa di un errore fatale, uccidere la pagina. Taglia le tue perdite e vai a casa. Se puoi continuare l'elaborazione, allora fallo.
But, what if the programmer uses Exceptions for debugging?
Perché dovresti inserire eccezioni speciali per il debug di in produzione? Certo, vai avanti e lancia eccezioni casuali in dev o test per testare la tua logica di gestione degli errori, ma in produzione vuoi essere come sicuro possibile. Specificamente per le applicazioni Web, questo significa:
-
Non perdere mai dati sensibili come percorsi del file system, nomi di file (ad esempio *.inc
file in PHP) o credenziali del database.
-
Non perdere mai le informazioni sullo schema del database anche per applicazioni note (ad esempio WordPress o altre applicazioni Web open source).
-
Non perdere mai nomi di variabili o altri dati interni che potrebbero fornire indizi di un utente malintenzionato su come sfruttare la tua applicazione web.
-
Non mostrare mai dati non pubblicitari.
-
Cerca sempre di dare all'utente un out: puoi almeno sputare un link per rendere più facile riprovare l'operazione o andare su una pagina sicura (es. /
)?