Domanda

Dopo un incidente sul posto di lavoro dove ho abusato String.IsNullOrEmpty con una variabile di sessione, un collega collega di mine ora rifiuta di accettare il mio utilizzo di String.IsNullOrEmpty. Dopo alcune ricerche, a quanto pare c'è un bug elencato per IsNullOrEmpty su MSDN ( link ) (vedi nota in fondo):

  

A partire dal 4 Aprile, 2006, c'è un bug   (Possibile nel JIT) che rende questo   metodo sicuro quando ottimizzazioni   acceso. E 'noto per influenzare sia   C # e VB.

Maggiori informazioni possono essere trovate qui ( link ) . Microsoft il bug è 'presunto' fissato post-Orcas, ma purtroppo il mio datore di lavoro utilizza ancora VS2005. Ma se il problema è stato risolto in 2008+ così sia. Questo è solo bene con me.

Mentre il rifiuto del mio collega del mio codice con IsNullOrEmpty per me è cieca ignoranza (IMO) di certo non può dirmi perché non da utilizzare in altro modo che l'uso improprio con la variabile di sessione. Ho usato IsNullOrEmpty tutto il nostro codice senza problemi di sorta. Personalmente, trovo molto più leggibile in aggiunta di fare le due cose in una dichiarazione.

Dopo googling per pareri in materia, ho i siti che prendono il pro / con posizione trovato. Ecco alcuni dei siti che ho letto su questo:

https://blog.rthand.com/post/2006 /06/22/1063.aspx

http://www.omegacoder.com/?p=105

Un sito ( http://dotnetperls.com/isnullorempty ) riassume il metodo (IMHO) abbastanza bene:

  

Qui abbiamo guardato che IsNullOrEmpty   metodo del tipo stringa, che   ci fornisce una buona e relativamente   metodo efficace di controllare se un   stringa è OK per salvare o utilizzare. Però,   per le prestazioni, può essere meglio   utilizzare i controlli nulli manuali. Le stringhe vuote   può anche essere testato in altri modi, e   la mia ricerca qui dimostra che il controllo   la lunghezza è il più veloce.

Supponendo che il bug fix è in atto (e funziona correttamente) in VS2008 / 2010 / ecc., V'è alcuna ragione per non di utilizzare String.IsNullOrEmpty con VS2005 e oltre? Mi rendo conto che può sembrare un po 'eccessivo per un po' di tale metodo sciocco, ma mi piacerebbe sapere se c'è più dietro le quinte in corso e se qualcuno ha spiegazioni alternative.

È stato utile?

Soluzione

Questo problema è stato risolto in .NET 2.0 SP1. Non v'è alcuna ragione per evitare il suo uso oggi.

Se si sta utilizzando .NET 2, si dovrebbe avere SP1 per molte altre ragioni in ogni modo -. Non vedo alcuna ragione per evitare questo per un bug che non esiste più

Altri suggerimenti

Ho sentito parlare di quel bug prima, e da quello che ho potuto capire che non si verifica mai in qualsiasi codice vero e proprio, solo nel codice come l'esempio che in realtà non fa nulla. Inoltre, il bug non è con il metodo IsNullOrEmpty stesso, in modo che si sarebbe verificato a prescindere da come si controlla la stringa.

Se il metodo fa esattamente quello che si vuole fare, lo deve usare. Tuttavia, non si dovrebbe usare in ogni situazione per verificare la presenza di una stringa vuota. A volte si vuole solo controllare se la stringa è vuota e non se si tratta di nulla.

Se la variabile stringa è nulla, questo sarà solo saltare il blocco di codice:

 if (!String.IsNullOrEmpty(str)) { ... }

Se la variabile stringa è nulla, ciò causerà un'eccezione:

 if (str.Length > 0) { ... }

Se la variabile non dovrebbe essere nullo, probabilmente si desidera l'eccezione al posto del codice di trattare il valore null come una stringa vuota. Se qualcosa non va si vuole prendere il più presto possibile, perché sarà più difficile rintracciare il problema torna alla sorgente del più l'eccezione è dalla causa.

si potrebbe scrivere uno unit test che passa una stringa vuota e uno che passa una stringa nulla per testare questa roba, ed eseguirlo in VS2005 e dopo nel 2008 e vedere cosa è successo

In tale relazione bug nel link si include afferma:

  

Questo bug è stato corretto in Microsoft .NET Framework 2.0 Service Pack 1 (SP1).

Dato che questo è il caso non dovrebbe importa se si sta utilizzando VS 2005 fino a quando si dispone di SP1 per .NET 2 installato.

Per quanto riguarda se o non usarlo, controlla questo messaggio di CodingHorror .

Usiamo un metodo di estensione per string.IsNullOrEmpty:

public static bool IsNullOrEmpty(this string target)
{
  return string.IsNullOrEmpty(target);
}

Con questo approccio, anche se fosse rotto in qualche versione precedente, un bugfix è solo una riga di codice.

E il valore aggiunto di poter utilizzare il metodo su un'istanza stringa che potrebbe essere nullo:

string myString = null;
if (myString.IsNullOrEmpty())
{
  // Still works
}

Sono abbastanza sicuro che è stato fissato sulla SP1, ma in ogni caso è possibile creare il proprio nullo o metodo vuoto:)

Come con qualsiasi lingua o parte di esso, è tutta una questione di conoscere i pro / contro e fare una decisione istruita sulla base di tali informazioni. IMHO.

Nell'attuazione argomento registrazione API, che di solito controllo per ogni condizione separatamente e getto diverse eccezioni: ArgumentNullException per un riferimento nullo o, a seconda delle specifiche API, ArgumentException per una stringa vuota. In questo caso, utilizzando String.IsNullOrEmpty non consente di distinguere tra queste due condizioni di errore separati.

if (str == null)
{
    throw new ArgumentNullException("str");
}
if (str == string.Empty)
{
    throw new ArgumentException("The string cannot be empty.", "str");
}

Se si è rotto nella versione, allora è banale per avere solo un metodo statico che farà il controllo, quindi basta fare:

public static bool isNull(String s) {
  return s == null || s.trim().length == 0;
}

Nessun punto a entrare in un grande problema per qualcosa che dovrebbe essere relativamente facile da risolvere.

Non è necessario cambiare ovunque, anche se si può fare un globale sostituzione di un metodo statico con un altro.

Mi chiedo perché la gente usa string.Empty, non è una buona cosa, perché è una stringa inizializzata e questo concetto esiste solo in Net telaio in tutto il mondo questa è una stringa valida con len di 0 (DB server rendono molto chiaro destinction tra questa e si lamentano se avete la logica controllo per nulla, ma si ottiene e stringa vuota). Credo che string.IsNullOrEmpty è uno dei primi 5 peggiori pratiche / funzioni che abbia mai visto perché in qualche modo incoraggia / fa apparire le persone ok init loro corde e possono essere trattati come nullo. Questa funzione dovrebbe non sono mai stati aggiunti e penso che i ragazzi .Net dovrebbero cercare di eliminare gradualmente fuori :) Chi ha bisogno e stringa vuota comunque? Non ho mai usato a meno che non ho dovuto a causa di progetti esistenti usavano

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top