Sprawdzanie, czy obiekt jest null w C#

C # 6 ma monadyczne sprawdzanie null :)

Przed:

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

Po:

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

Twój dataList jest null, ponieważ nie został utworzony, sądząc po kodzie, który opublikowałeś.

Try:

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;

}

[edytowane przez @ kelton52]

Najprostszy sposób to zrobić object.ReferenceEquals(null, data)

Ponieważ {[2] } nie ma gwarancji, że zadziała:

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));
}

Produkuje:

Porównując " z "Nully"

True

False

Nie, powinieneś używać !=. Jeśli data jest w rzeczywistości null, to twój program po prostu zawiesi się z NullReferenceException w wyniku próby wywołania metody Equals na null. Zdaj sobie również sprawę, że jeśli chcesz sprawdzić równość odniesienia, powinieneś użyć metody Object.ReferenceEquals, ponieważ nigdy nie wiesz, jak Equals została zaimplementowana.

Twój program się zawiesza, ponieważ dataList jest zerowy, ponieważ nigdy go nie inicjalizujesz.

Problemem w tym przypadku nie jest to, że data jest null. Jest to, że dataList sama w sobie jest null.

W miejscu gdzie deklarujesz dataList należy utworzyć nowy obiekt List i przypisać go do zmiennej.

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

W C# 7 najlepsze jest

if (obj is null) ...

To zignoruje any = = or != zdefiniowane przez obiekt (o ile oczywiście nie chcesz ich używać ...)

For not equal you can if (!(obj is null)) (Brzydula)

Oprócz @Jose Ortega odpowiedz, its better for use extension method

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

I użyj metody IsNull dla wszystkich obiektów takich jak:

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

Jeffrey L Whitledge ma rację. Twój " dataList-obiekt sam w sobie jest null.

Jest jeszcze jeden problem z Twoim kodem: używasz słowa kluczowego ref, co oznacza, że dane argumentów nie mogą być null! MSDN says:

Argument przekazany do parametru ref musi być najpierw zainicjowany. Różni się to od out, którego argumenty nie muszą być jawnie inicjalizowane przed ich przekazaniem

Nie jest też dobrym pomysłem używanie generyków z obiektem typu`. Leki generyczne powinny unikać boksu/rozpakowywania, a także zapewnić bezpieczeństwo typu. Jeśli chcesz mieć typ wspólny, stwórz metodę generyczną. Na koniec Twój kod powinien wyglądać tak:

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) {
        //...
      }
    }

Jak już zauważyli inni, nie jest to data, ale raczej prawdopodobne dataList, że jest to null. Poza tym...

catch-throw to antypattern, który prawie zawsze sprawia, że chcę wymiotować za każdym razem, gdy go widzę. Wyobraź sobie, że coś idzie nie tak głęboko w czymś, co doOtherStuff() nazywa. Wszystko co dostajesz to Exception obiekt, rzucony na throw w AddData(). Brak śladu stosu, brak informacji o połączeniach, brak stanu, nic, co wskazywałoby prawdziwe źródło problemu, chyba że wejdziesz i Przełącz swój debugger, aby złamać wyjątek wyrzucony, a nie wyjątek nieobsługiwany. Jeśli wyłapujesz wyjątek i po prostu rzucasz go ponownie w jakikolwiek sposób , szczególnie jeśli kod w bloku try jest w jakikolwiek sposób nietrywialny, zrób sobie (i swoim kolegom, obecnym i przyszłym) przysługę i wyrzuć cały try-catch blok. Oczywiście, {[11] } jest lepsze niż alternatywy, ale nadal dajesz sobie (lub komuś innemu próbuje naprawić błąd w kodzie) całkowicie niepotrzebne bóle głowy. Nie oznacza to, że try-catch-throw jest złem per se, o ile robisz coś istotnego z wyjątkiem obiektu, który został wyrzucony {19]} wewnątrz bloku catch.

Potem są potencjalne problemy z łapaniem Exception w pierwszej kolejności, ale to już inna sprawa, zwłaszcza, że w tym konkretnym przypadku rzucasz wyjątek.

Kolejną rzeczą, która wydaje mi się bardziej niż trochę niebezpieczna, jest to, że data może potencjalnie zmienić wartość podczas wykonywania funkcji, ponieważ przechodzisz przez odniesienie. Więc sprawdzenie null może przejść, ale zanim kod zrobi cokolwiek z wartością, zostanie zmieniony-być może na null. Nie jestem pewien, czy jest to problem, czy nie (może nie być), ale wydaje się, że warto na to uważać.

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

Użycie:

isnull(object.check.it)

Użycie warunkowe:

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

Aktualizacja (w inny sposób) zaktualizowano 31/08/2017. Dzięki za komentarz.

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

Podczas tworzenia obiektów klasy musisz sprawdzić, czy obiekt jest null, czy nie używając poniższego kodu.

Przykład: obiekt1 jest obiektem klasy

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