Dlaczego „odwołanie do obiektu nie jest ustawione na instancję obiektu” nie mówi nam, który obiekt?

Wprowadzamy system i czasami otrzymujemy słynny wyjątek NullReferenceExceptionz komunikatem Object reference not set to an instance of an object.

Jednak w metodzie, w której mamy prawie 20 obiektów, posiadanie dziennika, który mówi, że obiekt jest pusty, tak naprawdę w ogóle się nie przydaje. To tak, jakby powiedzieć, kiedy jesteś agentem bezpieczeństwa seminarium, że mężczyzna na 100 uczestników jest terrorystą. To naprawdę nie ma dla ciebie żadnego sensu. Powinieneś uzyskać więcej informacji, jeśli chcesz wykryć, który mężczyzna jest groźny.

Podobnie, jeśli chcemy usunąć błąd, musimy wiedzieć, który obiekt jest pusty.

Teraz coś mnie obsesję na punkcie od kilku miesięcy, a mianowicie:

Dlaczego .NET nie podaje nam nazwy, a przynajmniej rodzaju odwołania do obiektu, które jest puste? . Czy nie może zrozumieć typu z odbicia lub innego źródła?

Jakie są najlepsze praktyki, aby zrozumieć, który obiekt jest pusty? Czy zawsze powinniśmy ręcznie testować zerowanie obiektów w tych kontekstach i rejestrować wynik? Czy jest lepszy sposób?

Aktualizacja: wyjątek The system cannot find the file specifiedma ten sam charakter. Nie możesz znaleźć pliku, dopóki nie zostanie dołączony do procesu i debugowany. Myślę, że tego rodzaju wyjątki mogą stać się bardziej inteligentne. Czy nie byłoby lepiej, gdyby .NET mógł nam powiedzieć c:\temp.txt doesn't exist.zamiast tego ogólnego komunikatu? Jako programista głosuję na tak.

NullReferenceExceptionZasadzie mówi ci: robisz to źle. Nic dodać nic ująć. Wręcz przeciwnie, nie jest to pełne narzędzie do debugowania. W tym przypadku powiedziałbym, że robisz to źle, ponieważ

• istnieje wyjątek NullReferenceException
• nie zapobiegłeś temu w sposób, w jaki wiesz, dlaczego / gdzie to się wydarzyło
• a także może: metoda wymagająca 20 obiektów wydaje się nieco odległa

Jestem wielkim fanem sprawdzania wszystkiego, zanim coś pójdzie nie tak i zapewniania dobrych informacji deweloperowi. W skrócie: napisz czeki za pomocą ArgumentNullExceptioni polubień i napisz nazwisko. Oto próbka:

void Method(string a, SomeObject b)
{
    if (a == null) throw ArgumentNullException("a");
    if (b == null) throw ArgumentNullException("b");

    // See how nice this is, and what peace of mind this provides? As long as
    // nothing modifies a or b you can use them here and be 100% sure they're not
    // null. Should they be when entering the method, at least you know which one
    // is null.
    var c = FetchSomeObject();
    if(c == null)
    {
        throw InvalidOperationException("Fetching B failed!!");
    }

    // etc.
}

Możesz także zajrzeć do kontraktów kodowych , ma dziwactwa, ale działa całkiem dobrze i oszczędza ci pisania.

Naprawdę powinien pokazywać dokładnie to, co próbujesz zadzwonić. To tak, jakby powiedzieć: „Jest problem. Musisz go naprawić. Wiem, co to jest. Nie powiem ci. Idź to rozgryźć” Trochę jak połowa odpowiedzi na temat przepełnienia stosu, jak na ironię.

Jak przydatne byłoby, na przykład, jeśli masz to ...

Object reference (HttpContext.Current) not set to instance of an object

... Aby wejść do kodu, przejrzeć go i przekonać się, że to, co próbujesz wywołać, nulljest w porządku, ale dlaczego nie po prostu podać nam pomocną dłoń?

Zgadzam się, że zwykle przydatne jest przechodzenie przez kod, aby uzyskać odpowiedź (ponieważ prawdopodobnie dowiesz się więcej), ale często zaoszczędzono by dużo czasu i frustracji, gdyby NullReferenceExceptiontekst był bardziej podobny do powyższego przykładu.

Tylko mówię.

Twój dziennik powinien zawierać ślad stosu - zwykle daje wskazówkę, która linia w metodzie ma problem. Może być konieczne, aby kompilacja wydania zawierała symbole PDB, abyś miał pomysł, w której linii wystąpił błąd.

To prawda, że ​​nie pomoże ci w tym przypadku:

Foo.Bar.Baz.DoSomething()

Zasada „ nie pytaj ” może pomóc uniknąć takiego kodu.

Co do tego, dlaczego informacje nie są zawarte, nie jestem pewien - podejrzewam, że przynajmniej w kompilacji debugowania, jeśli naprawdę chcieliby, mogliby to zrozumieć. Pomoże Ci zrobienie zrzutu awaryjnego i otwarcie w WinDBG.

Stworzono wyjątki jako narzędzie do sygnalizowania wyjątkowych, nie kończących się śmiercią warunków w łańcuchu połączeń. Oznacza to, że nie zostały one zaprojektowane jako narzędzie do debugowania.

Gdyby wyjątek wskaźnika zerowego był narzędziem do debugowania, przerywałby on wykonywanie programu natychmiast, umożliwiając debugerowi połączenie się, kierując go bezpośrednio na linię obciążającą. Dałoby to programiście wszystkie dostępne informacje kontekstowe. (Co jest mniej więcej tym, co robi Segfault ze względu na zerowy dostęp do wskaźnika w C, choć trochę z grubsza.)

Jednak wyjątek wskaźnika zerowego został zaprojektowany jako poprawny warunek działania, który może zostać wygenerowany i przechwycony podczas normalnego przepływu programu. W związku z tym należy wziąć pod uwagę względy wydajności. Każde dostosowanie komunikatu wyjątku wymaga tworzenia, łączenia i niszczenia obiektów łańcuchowych w czasie wykonywania. Jako taki, statyczny komunikat jest bezsprzecznie szybszy.

Nie twierdzę jednak, że środowiska wykonawczego nie można zaprogramować w sposób, który dałby nazwę obciążającego odwołania. Można to zrobić. Sprawiłoby to, że wyjątki byłyby nawet wolniejsze niż są. Jeśli komuś na to zależy, taka funkcja może nawet zostać przełączona, aby nie spowalniała kodu produkcyjnego, ale pozwalała na łatwiejsze debugowanie; ale z jakiegoś powodu nikt nie dbał wystarczająco.

Cromulent uderzył w gwóźdź w głowę, ale myślę, że jest też oczywisty punkt, że jeśli dostajesz NullReferenceExceptionniezainicjowaną zmienną (zmienne). Argument, że masz około 20 obiektów przekazywanych do metody, nie może być uznany za złagodzenie: jako twórca fragmentu kodu musisz być odpowiedzialny za jego działania, w tym jego zgodność z resztą bazy kodu, ponieważ a także właściwe i prawidłowe wykorzystanie zmiennych itp.

jest uciążliwy, żmudny i czasem nudny, ale nagrody na końcu są tego warte: w wielu przypadkach musiałem przeszukiwać pliki dzienników ważące kilka gigabajtów i prawie zawsze są pomocne. Jednak zanim przejdziesz do tego etapu, debugger może ci pomóc, a przed tym etapem dobre planowanie zaoszczędzi wiele bólu (i nie mam też na myśli w pełni skonstruowanego podejścia do twojego kodu: proste szkice i niektóre notatki mogą i będą być lepszym niż nic).

Jeśli chodzi o Object reference not set to an instance of an objectkod, nie możemy zgadnąć, jakie wartości mogą nam się spodobać: to nasza praca jako programistów i oznacza to po prostu, że przekazałeś niezainicjowaną zmienną.

Naucz się korzystać z debugera. To jest dokładnie to, do czego jest przeznaczony. Ustaw punkt przerwania dla danej metody i gotowe.

Wystarczy przejść przez kod i zobaczyć dokładnie, jakie są wartości wszystkich zmiennych w określonych punktach.

Edycja: Szczerze mówiąc jestem zszokowany, że nikt jeszcze nie wspomniał o użyciu debuggera.

Jeśli chcesz skorzystać z odpowiedzi @ stijn i umieścić w kodzie kody zerowe, ten fragment kodu powinien pomóc. Oto kilka informacji o fragmentach kodu . Po skonfigurowaniu wystarczy wpisać argnull, dwukrotnie nacisnąć klawisz Tab, a następnie wypełnić puste pole.

<CodeSnippet Format="1.0.0">
  <Header>
    <Title>EnsureArgNotNull</Title>
    <Shortcut>argnull</Shortcut>
  </Header>
  <Snippet>
    <Declarations>
      <Literal>
        <ID>argument</ID>
        <ToolTip>The name of the argument that shouldn't be null</ToolTip>
        <Default>arg</Default>
      </Literal>
    </Declarations>
    <Code Language="CSharp">
      <![CDATA[if ($argument$ == null) throw new ArgumentNullException("$argument$");$end$]]>
    </Code>
  </Snippet>
</CodeSnippet>