Sprawdzanie, czy obiekt jest pusty w C #

Chciałbym zapobiec dalszemu przetwarzaniu obiektu, jeśli jest on pusty.

W poniższym kodzie sprawdzam, czy obiekt jest pusty przez:

if (!data.Equals(null))

i

if (data != null)

Jednak mogę otrzymać NullReferenceExceptionna dataList.Add(data). Jeśli obiekt był zerowy, nigdy nie powinien był nawet wejść do if-statement!

Dlatego pytam, czy to jest właściwy sposób sprawdzenia, czy obiekt jest pusty:

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

Jeśli jest to właściwy sposób sprawdzania, czy obiekt ma wartość null, co robię źle (jak mogę zapobiec dalszemu przetwarzaniu obiektu, aby uniknąć wyjątku NullReferenceException)?

To nie datatak null, ale dataList.

Musisz go utworzyć

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

Jeszcze lepiej: skoro to pole, zrób to private. A jeśli nic Cię nie powstrzyma, zrób to również readonly. Po prostu dobra praktyka.

Na bok

Prawidłowy sposób sprawdzenia nieważności to if(data != null). Ten rodzaj kontroli jest wszechobecny dla typów referencyjnych; nawet Nullable<T>zastępuje operator równości, aby był wygodniejszym sposobem wyrażania nullable.HasValuepodczas sprawdzania nieważności.

Jeśli to zrobisz if(!data.Equals(null)), otrzymasz NullReferenceExceptionif data == null. Co jest dość komiczne, ponieważ unikanie tego wyjątku było celem przede wszystkim.

Robisz to również:

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

To zdecydowanie nie jest dobre. Mogę sobie wyobrazić, że umieściłeś go tam tylko po to, abyś mógł włamać się do debuggera, wciąż będąc w metodzie, w którym to przypadku zignoruj ​​ten akapit. W przeciwnym razie nie wychwytuj wyjątków za darmo. A jeśli to zrobisz, rzuć je ponownie za pomocą just throw;.

w użyciu C #> 7.0

if (obj is null) ...

To zignoruje dowolne == lub! = Zdefiniowane przez obiekt (chyba że oczywiście chcesz ich użyć ...)

Do użytku nie zerowego if (obj is object)(lub if (!(obj is null)))

C # 6 ma monadyczne sprawdzanie wartości zerowej :)

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;

Twoja dataList ma wartość NULL, ponieważ nie została utworzona instancja, sądząc po opublikowanym kodzie.

Próbować:

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 w celu odzwierciedlenia podpowiedzi @ kelton52]

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

Ponieważ (null==data)NIE gwarantuje się działania:

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ównywanie „” z „Nully”

Prawdziwe

Fałszywe

Nie, powinieneś używać !=. Jeśli datafaktycznie jest zerowy, to twój program po prostu zawiesi się NullReferenceExceptionw wyniku próby wywołania Equalsmetody null. Pamiętaj również, że jeśli chcesz sprawdzić równość referencji, powinieneś użyć tej Object.ReferenceEqualsmetody, ponieważ nigdy nie wiesz, jak Equalszostała zaimplementowana.

Twój program ulega awarii, ponieważ dataListjest zerowy, ponieważ nigdy go nie inicjujesz.

Problem w tym przypadku nie datapolega na tym, że jest zerowy. To, że dataListsam jest null.

W miejscu, w którym deklarujesz dataList, powinieneś utworzyć nowy Listobiekt i przypisać go do zmiennej.

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

Oprócz odpowiedzi @Jose Ortega , jej lepsza metoda rozszerzenia wykorzystania

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

I użyj IsNullmetody dla wszystkich obiektów, takich jak:

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

Od wersji C # 8 możesz użyć wzorca właściwości „pusta” (z dopasowaniem wzorca ), aby upewnić się, że obiekt nie ma wartości zerowej:

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

To podejście oznacza „ jeśli obiekt odwołuje się do wystąpienia czegoś ” (tzn. Nie ma wartości null).

Możesz to traktować jako przeciwieństwo: if (obj is null)... . która zwróci true, gdy obiekt nie odwołuje się do instancji czegoś.

Aby uzyskać więcej informacji o wzorach w C # 8.0, przeczytaj tutaj .

Od wersji C # 9 możesz to zrobić

if (obj is null) { ... }

Do użytku nie zerowego

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

Jeśli musisz zastąpić to zachowanie, użyj ==i !=odpowiednio.

Jeffrey L Whitledge ma rację. Sam obiekt `dataList´ ma wartość NULL.

Istnieje również inny problem z twoim kodem: używasz słowa kluczowego ref, co oznacza, że ​​dane argumentu nie mogą mieć wartości null! MSDN mówi:

Argument przekazany do parametru ref musi zostać najpierw zainicjowany. Różni się to od naszego, którego argumentów nie trzeba jawnie inicjować przed ich przekazaniem

Nie jest również dobrym pomysłem stosowanie rodzajów ogólnych z typem „Obiekt”. Leki ogólne powinny unikać boksowania / rozpakowywania, a także zapewniać bezpieczeństwo typu. Jeśli chcesz mieć wspólny typ, uczyń swoją metodę ogólną. Wreszcie twój kod powinien wyglądać następująco:

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 inni już wspomniano, nie jest to datajednak dość prawdopodobne, dataListże jest null. W dodatku...

catch- throwjest antypatternem, 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()wzywa. Wszystko wrócisz to Exceptionprzedmiot, rzucony na throwIN AddData(). Brak śladu stosu, brak informacji o wywołaniu, brak stanu, nic, co wskazywałoby na prawdziwe źródło problemu, chyba że wejdziesz i przełączysz debugger na przerwanie zgłoszonego wyjątku zamiast wyjątku nieobsługiwanego. Jeśli wychwytujesz wyjątek i po prostu ponownie go rzucasz w jakikolwiek sposób , szczególnie jeśli kod w bloku try jest w jakikolwiek sposób nieistotny, zrób sobie (i swoim kolegom, obecnym i przyszłym) przysługę i wyrzuć całośćtry - catchblok . Zgoda,throw;jest lepsze niż alternatywy, ale wciąż dajesz sobie (lub ktokolwiek inny próbuje naprawić błąd w kodzie) zupełnie niepotrzebne bóle głowy. Nie oznacza to, że rzut próbny jest koniecznie zły sam w sobie, o ile zrobisz coś istotnego z rzuconym obiektem wyjątku do bloku catch.

Potem są potencjalne problemy z łapaniem Exception , ale to 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 datamoże potencjalnie zmienić wartość podczas wykonywania funkcji, ponieważ przechodzisz przez referencję. Kontrola zerowa może więc zakończyć się pomyślnie, ale zanim kod zacznie cokolwiek robić z wartością, zostanie zmieniona - być może na null. Nie jestem pewien, czy jest to problem, czy nie (może nie być), ale wydaje się, że warto na niego uważać.

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

posługiwać się:

isnull(object.check.it)

Zastosowanie warunkowe:

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

Aktualizacja (inna metoda) zaktualizowana 31.08.2017. Dziękuję za komentarz.

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

Za każdym razem, gdy tworzysz obiekty klasy, musisz sprawdzić, czy obiekt jest pusty, 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
  }
}

Właśnie zastosowałem metodę, którą zwykle stosujemy w skrypcie Java. Aby przekonwertować obiekt na ciąg, a następnie sprawdź, czy są one puste.

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

Zrobiłem prostszy (pozytywny sposób) i wydaje się, że działa dobrze.

Ponieważ jakikolwiek „obiekt” jest co najmniej przedmiotem

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