Verifica se un oggetto è nullo in C #

Vorrei impedire ulteriori elaborazioni su un oggetto se è nullo.

Nel seguente codice controllo se l'oggetto è nullo da uno dei due:

if (!data.Equals(null))

e

if (data != null)

Tuttavia, ricevo un NullReferenceExceptionat dataList.Add(data). Se l'oggetto era nullo, non avrebbe mai dovuto nemmeno entrare nello ifstato!

Pertanto, sto chiedendo se questo è il modo corretto di verificare se un oggetto è null:

public List<Object> dataList;
public  bool AddData(ref Object data)
    bool success = false;
    try
    {
        // I've also used "if (data != null)" which hasn't worked either
        if (!data.Equals(null))
        {
           //NullReferenceException occurs here ...
           dataList.Add(data);
           success = doOtherStuff(data);
        }
    }
    catch (Exception e)
    {
        throw new Exception(e.ToString());
    }
    return success;
}

Se questo è il modo corretto di verificare se l'oggetto è nullo, cosa sto facendo di sbagliato (come posso impedire ulteriori elaborazioni sull'oggetto per evitare NullReferenceException)?

Non è dataquello null, ma dataList.

Devi crearne uno con

public List<Object> dataList = new List<Object>();

Ancora meglio: dal momento che è un campo, fallo private. E se non c'è nulla che ti impedisce, fallo anche tu readonly. Solo buone pratiche.

A parte

Il modo corretto di verificare la nullità è if(data != null). Questo tipo di controllo è onnipresente per i tipi di riferimento; Nullable<T>ignora anche l'operatore di uguaglianza per essere un modo più conveniente di esprimere nullable.HasValuequando si verifica la nullità.

Se lo fai if(!data.Equals(null)), otterrai un NullReferenceExceptionif data == null. Che è un po 'comico da quando evitare questa eccezione è stato l'obiettivo in primo luogo.

Stai anche facendo questo:

catch (Exception e)
{
    throw new Exception(e.ToString());
}

Questo sicuramente non va bene. Posso immaginare di averlo messo lì solo per poter entrare nel debugger mentre sei ancora all'interno del metodo, nel qual caso ignora questo paragrafo. Altrimenti, non prendere eccezioni per niente. E se lo fai, ricodificali usando solo throw;.

in C #> 7.0 utilizzare

if (obj is null) ...

Questo ignorerà qualsiasi == o! = Definito dall'oggetto (a meno che ovviamente tu non voglia usarli ...)

Per uso non nullo if (obj is object)(o if (!(obj is null)))

C # 6 ha un controllo null monadico :)

prima:

if (points != null) {
    var next = points.FirstOrDefault();
    if (next != null && next.X != null) return next.X;
}   
return -1;

dopo:

var bestValue = points?.FirstOrDefault()?.X ?? -1;

Il tuo DataList è nullo in quanto non è stato istanziato, a giudicare dal codice che hai pubblicato.

Provare:

public List<Object> dataList = new List<Object>();
public  bool AddData(ref Object data)
bool success = false;
try
{
    if (!data.Equals(null))   // I've also used if(data != null) which hasn't worked either
    {
       dataList.Add(data);                      //NullReferenceException occurs here
       success = doOtherStuff(data);
    }
}
catch (Exception e)
{
    throw new Exception(e.ToString());
}
return success;

}

[Modificato per riflettere il suggerimento di @ kelton52]

Il modo più semplice è fare object.ReferenceEquals(null, data)

Poiché (null==data)NON è garantito il funzionamento:

class Nully
{
    public static bool operator ==(Nully n, object o)
    {
        Console.WriteLine("Comparing '" + n + "' with '" + o + "'");
        return true;
    }
    public static bool operator !=(Nully n, object o) { return !(n==o); }
}
void Main()
{
    var data = new Nully();
    Console.WriteLine(null == data);
    Console.WriteLine(object.ReferenceEquals(null, data));
}

produce:

Confronto '' con 'Nully'

Vero

falso

No, dovresti usare !=. Se dataè effettivamente nullo, il programma si arresterà in modo anomalo a NullReferenceExceptioncausa del tentativo di richiamare il Equalsmetodo null. Inoltre, tieni presente che, se desideri verificare specificamente l'uguaglianza di riferimento, dovresti utilizzare il Object.ReferenceEqualsmetodo in quanto non sai mai come Equalsè stato implementato.

Il programma si arresta in modo anomalo perché dataListè nullo poiché non viene mai inizializzato.

Il problema in questo caso non dataè null. È che dataListè di per sé nullo.

Nel punto in cui si dichiara dataListè necessario creare un nuovo Listoggetto e assegnarlo alla variabile.

List<object> dataList = new List<object>();

Oltre alla risposta @Jose Ortega , è meglio usare il metodo di estensione

 public static bool IsNull(this object T)
     {
        return T == null;
     } 

E usa il IsNullmetodo per tutti gli oggetti come:

object foo = new object(); //or any object from any class
if (foo.IsNull())
   {
     // blah blah //
   }

A partire da C # 8 è possibile utilizzare il modello di proprietà 'vuoto' (con corrispondenza del modello ) per assicurarsi che un oggetto non sia nullo:

if (obj is { })
{
    // 'obj' is not null here
}

Questo approccio significa " se l'oggetto fa riferimento a un'istanza di qualcosa " (ovvero non è nullo).

Si può pensare a questo come l'opposto di: if (obj is null).... che tornerà vero quando l'oggetto non fa riferimento a un'istanza di qualcosa.

Per maggiori informazioni sugli schemi in C # 8.0 leggi qui .

A partire da C # 9 puoi fare

if (obj is null) { ... }

Per uso non nullo

if (obj is not object) { ... }

Se è necessario ignorare questo comportamento, utilizzare ==e di !=conseguenza.

Jeffrey L Whitledge ha ragione. Il tuo oggetto `dataList´ stesso è nullo.

C'è anche un altro problema con il tuo codice: stai usando la parola chiave ref, il che significa che i dati dell'argomento non possono essere nulli! Il MSDN dice:

Un argomento passato a un parametro ref deve prima essere inizializzato. Ciò differisce da out, i cui argomenti non devono essere inizializzati esplicitamente prima di essere passati

Inoltre, non è una buona idea usare generici con il tipo "Oggetto". I generici dovrebbero evitare il pugilato / unboxing e garantire anche la sicurezza del tipo. Se vuoi un tipo comune, rendi generico il tuo metodo. Alla fine il tuo codice dovrebbe apparire così:

public class Foo<T> where T : MyTypeOrInterface {

      public List<T> dataList = new List<T>();

      public bool AddData(ref T data) {
        bool success = false;
        try {
          dataList.Add(data);                   
          success = doOtherStuff(data);
        } catch (Exception e) {
          throw new Exception(e.ToString());
        }
        return success;
      }

      private bool doOtherStuff(T data) {
        //...
      }
    }

Come altri hanno già sottolineato, non è, datama piuttosto probabile dataListche lo sia null. In aggiunta a ciò...

catch- throwè un antipasto che quasi sempre mi fa venir voglia di vomitare ogni volta che lo vedo. Immagina che qualcosa vada in profondità in qualcosa che doOtherStuff()chiama. Tutto ciò che ottieni è un Exceptionoggetto, lanciato throwdentro AddData(). Nessuna traccia dello stack, nessuna informazione sulla chiamata, nessuno stato, niente di tutto per indicare la vera fonte del problema, a meno che tu non entri e cambi il tuo debugger per interrompere l'eccezione generata anziché l'eccezione non gestita. Se si stanno recuperando un'eccezione e appena ri-gettandolo in alcun modo , in particolare se il codice nel blocco try è in alcun modo non banale, fare da soli (e vostri colleghi, presente e futuro) un favore e buttare via l'intero try- catchblocco . Certo,throw;è meglio delle alternative, ma ti stai ancora dando (o chiunque altro sta cercando di correggere un bug nel codice) mal di testa completamente inutili. Questo non vuol dire che try-catch-throw sia necessariamente male di per sé, purché si faccia qualcosa di rilevante con l'oggetto eccezione che è stato lanciato all'interno del blocco catch.

Quindi ci sono i potenziali problemi di cattura Exceptionin primo luogo, ma questa è un'altra questione, soprattutto perché in questo caso particolare si lancia un'eccezione.

Un'altra cosa che mi sembra più che un po 'pericolosa è che datapotrebbe potenzialmente cambiare valore durante l'esecuzione della funzione, poiché stai passando per riferimento. Quindi il controllo null potrebbe passare ma prima che il codice riesca a fare qualsiasi cosa con il valore, viene cambiato, forse in null. Non sono positivo se questa è una preoccupazione o meno (potrebbe non esserlo), ma sembra che valga la pena di fare attenzione.

  public static bool isnull(object T)
  {
      return T == null ? true : false;
  }

uso:

isnull(object.check.it)

Uso condizionale:

isnull(object.check.it) ? DoWhenItsTrue : DoWhenItsFalse;

Aggiornamento (un altro modo) aggiornato il 31/08/2017. Grazie per il commento.

public static bool isnull(object T)
{
    return T ? true : false;
}

Ogni volta che si creano oggetti di classe, è necessario verificare se l'oggetto è nullo o meno utilizzando il codice seguente.

Esempio: oggetto1 è oggetto di classe

void myFunction(object1)
{
  if(object1!=null)
  {
     object1.value1 //If we miss the null check then here we get the Null Reference exception
  }
}

Ho appena seguito un metodo che di solito seguiremmo nello script java. Per convertire l'oggetto in stringa e quindi verificare se sono nulli.

var obj = new Object();
var objStr = obj.ToString();
if (!string.IsNullOrEmpty(objStr)){
  // code as per your needs
}

Ho fatto più semplice (in modo positivo) e sembra funzionare bene.

Poiché ogni tipo di "oggetto" è almeno un oggetto

    if (MyObj is Object)
    {
            //Do something .... for example:  
            if (MyObj is Button)
                MyObj.Enabled = true;
    }