Dovresti lanciare un'eccezione se i valori di input di un metodo non sono compresi nell'intervallo? ad esempio
//no imaginary numbers
public int MySquareRoot(int x)
{
if (x<0)
{
throw new ArgumentOutOfBoundsException("Must be a non-negative integer");
}
//our implementation here
}
Ora questo metodo non dovrebbe mai essere chiamato con un numero non negativo, ma i programmatori hey commettono errori. Lanciare eccezioni qui è la cosa giusta da fare?
Sì, credo che dovresti fare un'eccezione, per aiutare i tuoi colleghi programmatori a notare l'errore in fase di compilazione, aggiungendo anche throws ArgumentOutOfBoundsException nella dichiarazione del metodo.
Cioè, a meno che non si utilizzino numeri immaginari nel progetto, dove -1 è un argomento perfettamente valido per il proprio metodo di radice quadrata. :)
Se puoi codificare il tuo metodo o la sua firma in modo tale che la condizione di eccezione non possa accadere, farlo è probabilmente l'approccio migliore.
Ad esempio, con l'esempio in particolare, la tua lingua ha un tipo di dati intero senza segno con un intervallo appropriato? In tal caso, basta usare quello invece di un corrispondente numero intero con segno e generare un'eccezione per qualsiasi valore passato che sia inferiore a 0. In tal caso, un valore negativo non può essere utilizzato in quella posizione in un programma ben formato; il compilatore prenderà l'errore molto prima del runtime, e almeno emetterà un avvertimento (per il tipo firmato / non firmato usare la mancata corrispondenza), a meno che non si faccia in modo di ignorare esplicitamente tale rete di sicurezza; e se stai forzando una variabile firmata in una funzione la cui firma del metodo dice solo un intero senza segno, assicurandoti che il valore sia all'interno di un intervallo accettabile per quella funzione, allora direi che il programmatore che lo fa merita di ottenere un'eccezione generata in faccia.
Come altro esempio, se solo un insieme di valori ragionevolmente piccolo è valido come input, forse quelli possono essere espressi come un'enumerazione con un insieme specifico di valori piuttosto che usare un valore intero semplice per codificare ogni possibile valore? Anche se sotto il cofano l'enum collassa a un int, usando le enumerazioni protegge dagli errori del programmatore.
Se non puoi scrivere la firma del metodo in modo tale che la condizione di eccezione non possa accadere in un programma ben formato, allora direi che questo è esattamente ciò che ArgumentOutOfRangeException , IllegalArgumentException e per i quali sono previsti tipi di eccezioni simili. Questo può anche essere banalmente lavorato in un flusso di lavoro TDD. Assicurati solo di chiarire quale sia l'errore , in particolare se non hai un facile accesso al codice sorgente, ottenere un ArgumentOutOfRangeException non specifico restituito a te può essere molto frustrante. Nota la documentazione per questi tipi di eccezioni:
ArgumentOutOfRangeException (.NET): "The exception that is thrown when the value of an argument is outside the allowable range of values as defined by the invoked method." (as seen here)
IllegalArgumentException (Java): "Thrown to indicate that a method has been passed an illegal or inappropriate argument." (as seen here)
Scrivere il metodo per rendere impossibile l'inizio della condizione di eccezione aiuterà molto di più che lanciare un'eccezione in fase di runtime, ma dobbiamo riconoscere che talvolta ciò non è possibile nella pratica. Tuttavia, sarà necessario verificare gli invarianti non direttamente correlati all'intervallo di un singolo valore del parametro in fase di runtime; ad esempio, se x + y > 20 è un errore, ma xey possono essere qualsiasi cosa < = 20, non penso che ci sia un modo semplice per esprimerlo nella firma del metodo.
Comprendo la tua domanda come " Dovresti convalidare i dati di input? ", invece di "Dovresti usare Eccezioni invece dei codici di errore?".
Quando accetti i parametri di input dall'esterno, che si tratti di un metodo con parametri di chiamata, dati di input XML da una chiamata di servizio o una pagina web con campi utente, hai fondamentalmente due scelte :
L'aggiunta di controlli aggiunge complessità
D'altro canto, la convalida dell'input offre preziosi vantaggi :
Quindi la scelta di aggiungere controlli dovrebbe essere eseguita nel contesto dove viene utilizzato il tuo metodo.
Se la tua domanda tuttavia era " Le eccezioni sono il modo giusto per segnalare i dati di input non validi? ", la risposta è: molto probabilmente sì .
Leeccezioni impongono un sovraccarico sulle prestazioni del runtime, ma rendono il ragionamento sul flusso del programma drasticamente più semplice. Ciò riduce la programmazione errata (errori semantici), soprattutto perché ti costringe a gestirli - essi "falliscono in modo sicuro" chiudendo il programma se vengono ignorati. Sono ideali per "situazioni che non dovrebbero accadere". Inoltre possono trasportare i metadati come uno stacktrace.
I codici di errore , d'altra parte, sono leggeri, veloci, ma costringono il chiamante del metodo a controllarli esplicitamente. In caso contrario, i difetti del programma, che possono variare da un danneggiamento silenzioso dei dati, buchi di sicurezza, a dei fuochi d'artificio se il tuo programma è in esecuzione all'interno di un razzo spaziale.
Un esempio in cui personalmente avrei preferito i codici di errore invece delle eccezioni è il metodo String.parseInt () in Java. Ottenere una stringa non digitata da una sorgente di input (ad es. Un utente) non è del tutto inaspettato e devo affrontarlo in ogni caso - a volte semplice come usare un valore predefinito. Come chiamante, non ho modo di controllare i dati se provocherebbe un'eccezione (a meno di implementare la logica di validazione da solo), generando così l'eccezione come parte del normale flusso di programma e l'utilizzo di blocchi try-catch è l'unica scelta qui .
Tieni presente che i codici di errore potrebbero essere sia in-band che out-of-band:
Se chiamo una funzione, mi aspetto che faccia qualcosa. Se non può fare ciò che ho richiesto, dovrei essere informato - la funzione non dovrebbe fare nulla o fare qualcosa di sbagliato.
Posso essere avvisato da esso restituendo un valore di ritorno specifico (ad esempio, una funzione sqrt in virgola mobile potrebbe restituire NaN per un numero errato), impostare una variabile di errore esterna o generare un'eccezione. (Il primo o il terzo sono preferiti.)
Nel tuo caso, la tua funzione non può fare ciò che viene richiesto quando x è minore di zero. Lanciare un'eccezione dicendo che l'argomento è fuori portata è perfettamente accettabile e ben informato.
Vorrei aggiungere un altro motivo per cui lanciare un'eccezione è la scelta migliore qui: unit test e TDD.
Ogni framework di testing maturo dovrebbe essere in grado di affermare che un determinato metodo genera quando si fornisce un determinato input. Scrivendo un test unitario che verifica tale eccezione, puoi documentare l'input valido e non valido per il metodo e allo stesso tempo convalidare che l'input non valido verrà effettivamente rifiutato.
Questo è molto più difficile quando si usano asserzioni (o qualche altro meccanismo).
Dovresti fare qualcosa, come questa risposta dice , le eccezioni sono utili, è buono per fallire -velocemente ecc. ecc. In effetti aggiungerei che aiutano nel tempo di lettura, direi che documentano meglio l'input desiderato rispetto al commento principale nel tuo esempio.
Tuttavia ci sono alternative. Se ho ipotizzato correttamente le tue lingue: Debug.Assert(x > 0) e Contract.Requires( x > 0 );
Tuttavia, il consenso sembra essere che usare le eccezioni in una build di rilascio è l'approccio migliore.
Gli avvisi sembrano destinati al debugging ed è più utile spedire con le eccezioni e che i Contracts non sono ancora abbastanza e non è buono per i metodi pubblici. Non è banale e non si presta a un rapido riassunto. Suggerisco di leggere quella pagina.
Nel complesso, tenderei a privilegiare le eccezioni, ma le affermazioni possono essere una scelta decente anche per i metodi interni.
Leggi altre domande sui tag exceptions exception-handling