In C #, ci sono buone ragioni (oltre a un messaggio di errore migliore) per aggiungere controlli null dei parametri a ogni funzione in cui null non è un valore valido? Ovviamente, il codice che usa s genererà comunque un'eccezione. E tali controlli rendono il codice più lento e difficile da mantenere.
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Risposte:
Sì, ci sono buone ragioni:
NullReferenceExceptionOra per quanto riguarda le tue obiezioni:
E per la tua affermazione:
Ovviamente, il codice che usa s genererà comunque un'eccezione.
Veramente? Ritenere:
void f(SomeType s)
{
// Use s
Console.WriteLine("I've got a message of {0}", s);
}
Questo usa s, ma non genera un'eccezione. Se non è valido per sessere nullo, e questo indica che qualcosa non va, un'eccezione è il comportamento più appropriato qui.
Ora dove metti quei controlli di convalida degli argomenti è una questione diversa. Puoi decidere di fidarti di tutto il codice all'interno della tua classe, quindi non preoccuparti dei metodi privati. Potresti decidere di fidarti del resto del tuo assembly, quindi non preoccuparti dei metodi interni. Quasi certamente dovresti convalidare gli argomenti a favore dei metodi pubblici.
Una nota a margine: l'overload del costruttore a parametro singolo di ArgumentNullExceptiondovrebbe essere solo il nome del parametro, quindi il tuo test dovrebbe essere:
if (s == null)
{
throw new ArgumentNullException("s");
}
In alternativa puoi creare un metodo di estensione, consentendo a un po 'più terser:
s.ThrowIfNull("s");
Nella mia versione del metodo di estensione (generico), faccio in modo che restituisca il valore originale se non è nullo, permettendoti di scrivere cose come:
this.name = name.ThrowIfNull("name");
Puoi anche avere un sovraccarico che non prende il nome del parametro, se non te ne preoccupi troppo.
ThrowIfEmptysuICollection
Debug.Assert. È ancora più importante rilevare gli errori nella produzione (prima che rovinino dati reali) che nello sviluppo.
throw new ArgumentNullException(nameof(s))
Sono d'accordo con Jon, ma aggiungerei una cosa a questo.
Il mio atteggiamento su quando aggiungere controlli nulli espliciti si basa su queste premesse:
throwle dichiarazioni sono dichiarazioni .ifè una dichiarazione .throwinif (x == null) throw whatever;Se non è possibile eseguire tale istruzione, non può essere testata e deve essere sostituita con Debug.Assert(x != null);.
Se esiste un modo possibile per eseguire quell'istruzione, scrivi l'istruzione, quindi scrivi uno unit test che lo eserciti.
È particolarmente importante che i metodi pubblici di tipo pubblico controllino i loro argomenti in questo modo; non hai idea di quale follia faranno i tuoi utenti. Dai loro il "hey testa di ossa, stai sbagliando!" eccezione il prima possibile.
I metodi privati dei tipi privati, al contrario, hanno molte più probabilità di trovarsi nella situazione in cui controlli gli argomenti e possono avere una forte garanzia che l'argomento non sia mai nullo; utilizzare un'asserzione per documentare tale invariante.
Senza un ifcontrollo esplicito , può essere molto difficile capire cosa fosse nullse non si possiede il codice.
Se ottieni un NullReferenceExceptiondal profondo di una libreria senza codice sorgente, è probabile che tu abbia molti problemi a capire cosa hai sbagliato.
Questi ifcontrolli non renderanno il tuo codice notevolmente più lento.
Notare che il parametro per il ArgumentNullExceptioncostruttore è un nome di parametro, non un messaggio.
Il tuo codice dovrebbe essere
if (s == null) throw new ArgumentNullException("s");
Ho scritto uno snippet di codice per renderlo più semplice:
<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
<CodeSnippet Format="1.0.0">
<Header>
<Title>Check for null arguments</Title>
<Shortcut>tna</Shortcut>
<Description>Code snippet for throw new ArgumentNullException</Description>
<Author>SLaks</Author>
<SnippetTypes>
<SnippetType>Expansion</SnippetType>
<SnippetType>SurroundsWith</SnippetType>
</SnippetTypes>
</Header>
<Snippet>
<Declarations>
<Literal>
<ID>Parameter</ID>
<ToolTip>Paremeter to check for null</ToolTip>
<Default>value</Default>
</Literal>
</Declarations>
<Code Language="csharp"><![CDATA[if ($Parameter$ == null) throw new ArgumentNullException("$Parameter$");
$end$]]>
</Code>
</Snippet>
</CodeSnippet>
</CodeSnippets>
Potresti voler dare un'occhiata ai contratti di codice se hai bisogno di un modo migliore per assicurarti di non ottenere alcun oggetto nullo come parametro.
Il vantaggio principale è che sei esplicito con i requisiti del tuo metodo fin dall'inizio. Ciò rende chiaro agli altri sviluppatori che lavorano sul codice che è veramente un errore per un chiamante inviare un valore nullo al tuo metodo.
Il controllo interromperà anche l'esecuzione del metodo prima che venga eseguito qualsiasi altro codice. Ciò significa che non dovrai preoccuparti delle modifiche apportate dal metodo che vengono lasciate incompiute.
Salva un po 'di debug, quando si colpisce quell'eccezione.
ArgumentNullException afferma esplicitamente che era "s" che era null.
Se non hai quel controllo e lasci che il codice esploda, ottieni una NullReferenceException da una riga non identificata in quel metodo. In una build di rilascio non ottieni i numeri di riga!
Codice originale:
void f(SomeType s)
{
if (s == null)
{
throw new ArgumentNullException("s cannot be null.");
}
// Use s
}
Riscrivilo come:
void f(SomeType s)
{
if (s == null) throw new ArgumentNullException(nameof(s));
}
Il motivo per riscrivere utilizzando nameofè che consente un refactoring più semplice. Se il nome della variabile scambia, verranno aggiornati anche i messaggi di debug, mentre se si codifica semplicemente il nome della variabile, alla fine sarà obsoleto quando gli aggiornamenti vengono effettuati nel tempo. È una buona pratica utilizzata nell'industria.
int i = Age ?? 0;
Quindi per il tuo esempio:
if (age == null || age == 0)
O:
if (age.GetValueOrDefault(0) == 0)
O:
if ((age ?? 0) == 0)
O ternario:
int i = age.HasValue ? age.Value : 0;