precondizioni ed eccezioni

Question

Supponi di avere un metodo con alcune condizioni pre e post. È possibile creare una classe di eccezione per ogni pre-condizione che non viene raggiunta? Per esempio: Non realizzare pre1 significa lanciare un'istanza notPre1Exception.

Answer 1

Sì e no.

Sì. La violazione di una precondizione è sicuramente il momento opportuno per generare un'eccezione. Lanciare un'eccezione più specifica renderà più semplice la cattura di quell'eccezione specifica.

No - La dichiarazione di una nuova classe di eccezione per ogni condizione preliminare nel programma / API sembra eccessiva. Ciò potrebbe comportare alla fine centinaia o migliaia di eccezioni. Questo sembra uno spreco sia mentalmente che computazionalmente.

Consiglierei di gettare eccezioni per le violazioni delle condizioni preliminari. Tuttavia, non consiglierei di definire una nuova eccezione per ogni condizione preliminare. Invece, raccomanderei di creare classi più ampie di eccezioni che coprano uno specifico tipo di violazione delle precondizioni, piuttosto che una specifica violazione delle precondizioni. (Consiglierei anche di usare le eccezioni esistenti dove si adattano bene.)

Answer 2

Perché non dovresti definire PreconditionFailedException (precondizione di stringa)? Lanciare un diverso tipo di eccezione per ogni precondizione fallita è eccessivo.

Answer 3

Una precondizione non riuscita dovrebbe generare una AssertException o qualcosa di simile. Prima di invocare un metodo, è necessario che sia necessario. Se il chiamante non esegue questo controllo, è un bug nel programma o un uso errato del metodo (API).

Answer 4

Solo se non si soddisfano le condizioni preliminari sarebbe un raro evento eccezionale .

Answer 5

Mi sembra un utile utilizzo delle eccezioni. Ciò consente certamente una registrazione e un debug più dettagliati di una semplice "precondizione non riuscita", sebbene si possa anche avere un'unica eccezione "precondizioni fallite" e inserire quali precondizioni sono fallite nel messaggio di eccezione.

Answer 6

Penso che sia giusto creare un'eccezione diversa per tutte le tue eccezioni purché tu preveda di utilizzarle e gestirle.

Ho scoperto che migliore è la gestione dell'errore / eccezione, più facile è il debug del software nelle fasi successive.

Ad esempio: se si dispone di un excpeiton generico per gestire tutti gli input errati, è necessario esaminare tutto ciò che è stato passato al metodo in caso di errore. Se hai un'esclusione di tutti i tipi di cattive condizioni, saprai esattamente dove cercare.

Answer 7

Mi sembra possibile, ma se vuoi continuare questo modo di trattare i presupposti, finirai con N classi di eccezioni per metodo di classe. Sembra una crescita esplosiva di classi "non funzionali".

Mi è sempre piaciuto il codice in cui la funzionalità 'core' non gestiva la violazione dei presupposti (a parte affermarli - un grande aiuto!). Questo codice può quindi essere racchiuso in un "controllo preliminare", che fa genera eccezioni o notifica in caso contrario di non soddisfazione.

Answer 8

Come modo molto generico per determinare se è necessario creare o meno una classe (e un'eccezione è una classe), è necessario determinare se esiste un codice che rende questa classe unica rispetto a tutte le altre classi (in questo caso eccezioni).

In caso contrario, impostarei la stringa nell'eccezione e la chiamerei un giorno. Se stai eseguendo il codice nella tua eccezione (forse un meccanismo di recupero generico in grado di gestire più situazioni chiamando exception.resolve () o qualcosa del genere), potrebbe essere utile.

Mi rendo conto che le eccezioni non seguono sempre questa regola, ma penso che sia più o meno perché le eccezioni fornite dalla lingua non possono avere alcuna logica aziendale (perché non conoscono l'attività - le biblioteche sempre tende ad essere pieno di eccezioni alle regole OO)

Answer 9

Penso che Ben sia l'obiettivo qui. A che serve lanciare diverse eccezioni se non le prenderai? Se vuoi davvero lanciarne uno diverso, avrei almeno un comune "PreconditionFailedException" classe base da cui derivano tutti, e cerca di organizzarli in una sorta di erede in modo da poter catturare gruppi di essi. Personalmente, non ne avrei di diversi e avrei solo un'eccezione comune da lanciare con i dettagli del fallimento in ognuno.

Answer 10

No, non dovresti creare un'eccezione specifica per ogni condizione preliminare perché andrà contro i principi del Design-by-Contract.

Il corollario dell'implementazione delle pre-condizioni è che dovrebbero essere parte della documentazione e che dovresti fornire i metodi necessari affinché il chiamante possa verificare che tutte le condizioni preliminari siano valide. (ovvero se l'esecuzione di un metodo si basa sullo stato di un oggetto, il metodo per verificare lo stato dovrebbe essere disponibile per il chiamante).

Quindi, il chiamante dovrebbe essere in grado di verificare se tutti i prerequisiti sono soddisfatti prima di chiamare il metodo.

L'implementazione di eccezioni specifiche per ogni pre-condizione violata potrebbe / potrebbe incoraggiare il chiamante a utilizzare il modello try / catch attorno alla chiamata del metodo, cosa che è in contraddizione con la filosofia del Design-by-Contract.

Answer 11

Direi che va bene fintanto che li fai eccezioni non controllate (sottoclasse di RuntimeException in Java). Tuttavia, in Java è meglio usare solo le asserzioni.

Answer 12

In questo caso, assicurati che ereditino tutti da un'altra eccezione personalizzata comune.