Un'applicazione dovrebbe recuperare da un'eccezione generata in PHP?

2

Cosa succede se il programmatore utilizza Eccezioni per il debug? Sarebbe meglio in questo caso segnalare l'errore e interrompere immediatamente lo script poiché idealmente tutti i bug dovrebbero essere risolti in modo radicale?

È un modo corretto di usare le eccezioni in PHP?

Lettura correlata: eccezioni in PHP

Grazie

    
posta mikl 05.06.2015 - 19:33
fonte

3 risposte

3

Ciò che probabilmente stai cercando sono asserzioni , non eccezioni.

In generale, le eccezioni dovrebbero essere generate quando qualcosa di brutto sta accadendo che non si può fare nulla nell'attuale ambito del codice. Ad esempio, lo scopo della tua funzione è aprire un file, ma il file specificato nel parametro della funzione non è presente sul supporto di memorizzazione.

Le eccezioni non dovrebbero essere usate come meccanismo di debug generalizzato. Se vuoi sapere se qualcosa sta accadendo o meno in uno script, registralo, acquisisci il comportamento in un unit test o esaminalo usando un debugger, piuttosto che usare un'eccezione.

Le eccezioni segnalano qualcosa che ti aspetti che succeda, anche se si tratta di una condizione di errore di cui non puoi fare nulla. Potresti ragionevolmente aspettarti che qualcuno ti dia il percorso di un file che non esiste. Ma ciò non significa che il tuo codice non sia corretto; significa solo che il chiamante non ha fornito le condizioni adeguate per avere successo.

Le asserzioni sono diverse; segnalano un problema con il tuo codice. Sono più semanticamente corretti da usare a scopo di debugging rispetto alle eccezioni, che hanno uno scopo diverso.

    
risposta data 05.06.2015 - 19:45
fonte
0

Dipende

In base a ciò che sta facendo l'applicazione e la necessità della funzione che ha generato l'eccezione determinerà se fallire immediatamente o continuare l'elaborazione.

Ad esempio:

Scenario 1:

User attempts to update their password.

Password hashing function fails and throws an exception

In questo caso l'applicazione dovrebbe interrompersi immediatamente e visualizzare un errore all'utente.

Scenario 2:

User is navigating through site, interacting normally

Process updates last seen timestamp (ie- this user was last seen 5 minutes ago...)

Update fails and throws an exception

In questo caso, direi, l'applicazione dovrebbe fallire silenziosamente (ma sta ancora registrando il problema) e continuare a funzionare normalmente dal punto di vista dell'utente.

In sostanza, se la funzionalità critica è interrotta a causa di un'eccezione, interrompere immediatamente, altrimenti degradare con garbo (e registrare).

    
risposta data 05.06.2015 - 19:45
fonte
0

Questo non è specifico per PHP, quindi risponderò al caso generale.

Ci sono due tipi di errori nelle applicazioni web:

  1. Script non inizializzato. Esempi: impossibile connettersi al database; file di intestazione richiesto non trovato; altro errore fatale.

  2. 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. / )?

risposta data 05.06.2015 - 19:52
fonte

Leggi altre domande sui tag