Comprensione dei casi eccezionali

3

Ho studiato l'uso delle eccezioni in vari progetti di php (come Doctrine e Zend Framework). Le eccezioni sembrano essere generate quando si verifica uno stato / input non valido. Un esempio perfetto è Doctrine che genera un'eccezione quando si tenta di utilizzare una stringa di query non valida.

Penso che i creatori della dottrina api abbiano capito che, per prima cosa, non è possibile interrogare i dati usando un'istruzione DQL non valida e uno sviluppatore dovrebbe essere immediatamente avvisato che si è verificato un errore, piuttosto che lasciare che l'esecuzione continui con la possibilità di un codice di errore non controllato. Scommetto anche che questo semplifica la lettura del codice. Non riesco a pensare a una situazione in cui si desideri utilizzare una dichiarazione DQL non valida, ad eccezione del test delle unità. Poiché questo è vero, è meglio evitare di affliggere un gruppo di codice con controlli null / errori e utilizzare le eccezioni.

Ho letto nei libri che le eccezioni non dovrebbero essere generate quando si convalida l'input dell'utente di appuntamenti. Ho visto esempi su dove si è rotta la linea guida. Un esempio è il framework Zend. Se si fornisce un controller o un nome di azione non valido, viene generata un'eccezione. A differenza della dottrina, l'utente ha un controllo più diretto su questo tipo di input. So che puoi configurare un controller degli errori e impostare un messaggio 404 o cosa hai, ma sono curioso del motivo per cui hanno usato un'eccezione in questo scenario? Suppongo che tu possa sostenere che Zend Framework non sa come continuare ad elaborare la richiesta.

Un ultimo esempio Ho scritto una funzione per restituire un codice HTML basato su un determinato tipo di risorsa. Questo tipo di risorsa è codificato e inviato quando un utente interagisce con un sito Web (ad esempio facendo clic su un pulsante per visualizzare il modulo per immettere dati). Non mi aspetto che gli utenti debbano andare in giro con il tipo di richiesta. In condizioni operative normali, il tipo di risorsa dovrebbe essere valido. Per ripulire la logica, avrei lanciato un'eccezione se non fosse stato trovato un particolare modulo. Questo è principalmente per trovare la forma corretta associata a un tipo di risorsa, in modo che possa avvenire una corretta convalida. Questo suona come un caso d'uso valido per un'eccezione? Al momento è piuttosto banale, ma ho intenzione di implementare un consumatore riposante e riutilizzare una funzione per mappare le risorse ai loro servizi di validazione sarebbe molto utile. Posso quindi rilevare l'eccezione e in base al consumatore, restituire un messaggio di errore adatto al tipo di richiesta ...

    
posta Justin 12.11.2013 - 08:28
fonte

2 risposte

4

Le eccezioni dovrebbero essere lanciate in casi eccezionali, come una circostanza in cui il file previsto non esiste, o quando la rete è inattiva, o quando ci vuole più di un minuto per aprire la connessione al database.

L'input dell'utente sbagliato non è un caso eccezionale. Potrebbe anche non essere un errore. Ad esempio, inserire "ventisei" nel campo La tua età non è un errore dal punto di vista degli utenti, ma la maggior parte delle applicazioni non sarebbe in grado di gestire questo input come valido.

Invece di lanciare un'eccezione, l'app dovrebbe validare l'input e, se davvero non può essere analizzato, restituire la risposta HTML indicando ciò che è previsto come input, o, in un contesto di AJAX, un JSON con il dettagli sull'input non valido.

Questa è la teoria.

In pratica, framework come Zend Framework o ASP.NET MVC ricorrono alle eccezioni, perché non esiste un modo elegante per gestire input non validi. Sono quadri, non app. Ciò significa che a un certo punto, dovrebbero / possono / potrebbero passare le informazioni come "Ehi, non posso analizzare il campo Età come numero!" all'applicazione. Il modo meno brutto per farlo sembra usare le eccezioni.

    
risposta data 12.11.2013 - 08:48
fonte
0

Si dovrebbero restituire le indicazioni di errore per le cose che un chiamante immediato è pronto a gestire e le eccezioni per cose che un chiamante immediato non è pronto a gestire. Se si verificano condizioni durante l'esecuzione di un'azione che alcuni chiamanti immediati saranno pronti a gestire ma non altri chiamanti immediati, potrebbe essere utile avere un metodo che restituirà un'indicazione di errore in tali casi (per l'uso da chiamanti che si aspettano il condizione) e un altro metodo che genererà un'eccezione (per i chiamanti che non sarebbero in grado di fare nulla nel caso di errore tranne che lanciare loro stessi un'eccezione).

    
risposta data 09.07.2014 - 21:59
fonte

Leggi altre domande sui tag