unikanie WYJĄTKÓW null reference

Oprócz powyższych (Null Objects, Empty Collections), istnieje kilka ogólnych technik, mianowicie pozyskiwanie zasobów jest inicjalizacją (RAII) z C++ i Design by Contract z Eiffla. Sprowadzają się do:

1. Zainicjalizuj zmienne poprawnymi wartościami.
2. jeśli zmienna może być null, to albo sprawdź null i traktuj ją jako specjalny przypadek, albo oczekuj wyjątku od null (i radź sobie z tym). Twierdzenia mogą być wykorzystane do badania naruszeń umowy w rozwój buduje.

Widziałem sporo kodu, który wygląda tak:

If ((wartość != null) & & (value.getProperty() != null)&&... && (...doSomethingUseful ())

Przez większość czasu jest to całkowicie niepotrzebne i większość testów może zostać usunięta z bardziej rygorystyczną inicjalizacją i ściślejszymi definicjami umów.

Jeśli jest to problem w bazie kodu, to konieczne jest zrozumienie w każdym przypadku, co null reprezentuje:

1. Jeśli null reprezentuje pustą kolekcję, Użyj pustej kolekcji.
2. Jeśli null reprezentuje wyjątkowy przypadek, wyrzuć wyjątek.
3. Jeśli null reprezentuje przypadkowo niezainicjalizowaną wartość, jawnie ją zainicjuj.
4. Jeśli null reprezentuje legalną wartość, przetestuj ją - lub jeszcze lepiej Użyj obiektu NullObject, który wykonuje operację null.

W praktyce ten standard jasności na poziomie projektu jest nietrywialny i wymaga wysiłek i samodyscyplina, aby konsekwentnie stosować się do bazy kodu.

Nie wiesz.]}

A raczej, nie ma nic specjalnego do zrobienia, aby spróbować 'zapobiec' NREs w C#. W większości przypadków NRE to tylko jakiś rodzaj błędu logicznego. Możesz je zapalić na granicach interfejsu, sprawdzając parametry i mając dużo kodu, takiego jak

void Foo(Something x) {
    if (x==null)
        throw new ArgumentNullException("x");
    ...
}

Wszędzie (większość. Net Framework tak robi), tak, że kiedy nawalisz, otrzymasz nieco bardziej pouczającą diagnostykę (ślad stosu jest jeszcze bardziej wartościowy, a NRE również to zapewnia). Ale i tak kończysz z wyjątkiem.

(pomijając: wyjątki takie jak te-Nullreferencexception, ArgumentNullException, ArgumentException, ... - zazwyczaj nie powinien być złapany przez program, ale raczej oznacza po prostu "twórca tego kodu, jest błąd, proszę go naprawić". Odnoszę się do nich jako wyjątki "design time"; kontrastuję je z prawdziwymi wyjątkami "run time", które zdarzają się w wyniku środowiska run time (np. FileNotFound) i mają potencjalnie zostać przechwycone i obsługiwane przez program.)

Idealnie, większość NREs nigdy by się nie wydarzyła, ponieważ 'null' jest nonsensowną wartością dla wielu typów / zmiennych,a idealnie STATYCZNY system typów nie zezwala na 'null' jako wartość dla tych konkretnych typów/zmiennych. Wtedy kompilator uniemożliwiłby wprowadzenie tego typu przypadkowego błędu (wykluczając pewne klasy błędów są to, co kompilatory i systemy typów są najlepsze at). To tutaj wyróżnia się niektóre języki i systemy typów.

Ale bez tych funkcji, po prostu testujesz swój kod, aby upewnić się ,że nie masz ścieżek kodu z tego typu błędem(lub ewentualnie użyj zewnętrznych narzędzi, które mogą wykonać dodatkową analizę).

Użycie wzorców obiektów Null jest tutaj kluczowe.

Upewnij się, że zbiory muszą być puste w przypadku, gdy nie są wypełnione, a nie null. Używanie kolekcji null, gdy zrobi to pusta kolekcja, jest mylące i często niepotrzebne.

Wreszcie, w miarę możliwości, moje obiekty sprawdzają wartości inne niż null podczas budowy. W ten sposób nie mam wątpliwości, czy wartości są null, i muszę tylko wykonać null checks gdzie essential . Dla większości moich pól i parametrów mogę założyć, że wartości nie są null na podstawie poprzednich twierdzeń.

Jednym z najczęstszych błędów odniesienia null, które widziałem, jest łańcuch. Będzie czek:

if(stringValue == "") {}

Ale, łańcuch jest naprawdę null. Powinno być:

if(string.IsNullOrEmpty(stringValue){}

Ponadto, możesz być zbyt ostrożny i sprawdzić, czy obiekt nie jest null, zanim spróbujesz uzyskać dostęp do członków / metod tego obiektu.

Możesz łatwo sprawdzić, czy odniesienie null nie powoduje wyjątku, ale zazwyczaj nie jest to prawdziwy problem, więc i tak wyrzucisz wyjątek, ponieważ kod nie może być kontynuowany bez żadnych danych.

Często głównym problemem nie jest fakt, że masz odniesienie null, ale że masz odniesienie null w pierwszej kolejności. Jeśli odniesienie nie ma być null, nie powinieneś ominąć punktu, w którym odniesienie jest inicjalizowane bez posiadania odpowiedniego Referencja.

Jednym ze sposobów jest użycie obiektów z wartością Null (aka wzorzec obiektu Null ) tam, gdzie to możliwe. Tutaj znajdziesz Więcej Szczegółów

Naprawdę, jeśli w Twoim języku są wartości null, to na pewno się stanie. Null reference errors pochodzą z błędów w logice aplikacji - więc jeśli nie możesz uniknąć wszystkich tych, które na pewno trafisz.

Odpowiednie użycie strukturalnej obsługi wyjątków może pomóc uniknąć takich błędów.

Testowanie jednostkowe może również pomóc upewnić się, że kod zachowuje się zgodnie z oczekiwaniami, w tym upewnić się, że wartości nie są null, gdy nie powinny być.

Jednym z najprostszych sposobów uniknięcia NullReferenceExceptions jest agresywne sprawdzanie referencji null w konstruktorach klas/metodach / ustawiaczach właściwości i zwrócenie uwagi na problem.

Np.

public MyClass
{
   private ISomeDependency m_dependencyThatWillBeUsedMuchLater 

   // passing a null ref here will cause 
   // an exception with a meaningful stack trace    
   public MyClass(ISomeDependency dependency)
   {
      if(dependency == null) throw new ArgumentNullException("dependency");

      m_dependencyThatWillBeUsedMuchLater = dependency;
   }

   // Used later by some other code, resulting in a NullRef
   public ISomeDependency Dep { get; private set; }
}

W powyższym kodzie, jeśli przekażesz null ref, natychmiast dowiesz się, że kod wywołujący używa tego typu nieprawidłowo. Jeśli nie było sprawdzania null reference, błąd może zostać przysłonięty na wiele różnych sposobów.

Zauważysz, że. NET framework biblioteki prawie zawsze zawodzą wcześnie i często, jeśli podasz odwołania null tam, gdzie jest to nieprawidłowe. Ponieważ wyjątek rzucony wyraźnie mówi "nawaliłeś!"i mówi ci dlaczego, sprawia, że wykrywanie i korygowanie wadliwego kodu jest banalnym zadaniem.

Słyszałem skargi od niektórych programistów, którzy twierdzą, że ta praktyka jest zbyt gadatliwa i zbędna, ponieważ Nullreferencexception jest wszystkim, czego potrzebujesz, ale w praktyce uważam, że robi to dużą różnicę. Jest to szczególnie w przypadku, gdy połączenie stos jest głęboki i / lub parametr jest przechowywany, a jego użycie jest odroczone na później (być może w innym wątku lub zasłonięte w inny sposób).

Co byś wolał, ArgumentNullException przy metodzie wejścia, czy niejasny błąd w bebechach? Im dalej oddalasz się od źródła błędu, tym trudniej jest go wyśledzić.

Dobre narzędzia do analizy kodu mogą tu pomóc. Dobre testy jednostkowe mogą również pomóc, jeśli używasz narzędzi, które uważają null za możliwą ścieżkę do kodu. Spróbuj wrzucić ten przełącznik w Ustawieniach kompilacji, który mówi "traktuj ostrzeżenia jako błędy" i sprawdź, czy możesz zachować # ostrzeżeń w projekcie = 0. Może się okazać, że ostrzeżenia mówią ci wiele.

Należy pamiętać, że może to byćdobra rzecz , że rzucasz wyjątek null - reference. Dlaczego? ponieważ to może oznaczać, że kod, który powinien został wykonany nie. Inicjowanie wartości domyślnych jest dobrym pomysłem, ale należy uważać, aby nie ukryć problemu.

List<Client> GetAllClients()
{
    List<Client> returnList = new List<Client>;
    /* insert code to go to data base and get some data reader named rdr */
   for (rdr.Read()
   {
      /* code to build Client objects and add to list */
   }

   return returnList;
}

W porządku, więc może to wyglądać dobrze, ale w zależności od twoich zasad biznesowych, może to być problem. Oczywiście, nigdy nie rzucisz odniesienia null, ale może Twoja tabela użytkownika nigdy nie powinna być pusta? Czy chcesz, aby Twoja aplikacja kręciła się w miejscu, generując połączenia wsparcia od użytkowników mówiących "to tylko pusty ekran", lub czy chcesz zgłosić wyjątek, który może zostać gdzieś zarejestrowany i szybko ogłosić alert? Nie zapomnij zweryfikować tego, co robisz, a także "obsługiwać" wyjątki. Jest to jeden z powodów, dla których niektórzy brzydzą się usuwaniem null z naszych języków... ułatwia to znalezienie błędów, nawet jeśli może to spowodować kilka nowych.

Pamiętaj: obsługuj wyjątki, nie ukrywaj ich.

Plain Code Solution

Zawsze można utworzyć strukturę, która pomaga wcześniej wychwycić null reference errors, oznaczając zmienne, właściwości i parametry jako "not nullable". Oto przykład koncepcyjnie wzorowany na sposobie działania Nullable<T>:

[System.Diagnostics.DebuggerNonUserCode]
public struct NotNull<T> where T : class
{
    private T _value;

    public T Value
    {
        get
        {
            if (_value == null)
            {
                throw new Exception("null value not allowed");
            }

            return _value;
        }
        set
        {
            if (value == null)
            {
                throw new Exception("null value not allowed.");
            }

            _value = value;
        }
    }

    public static implicit operator T(NotNull<T> notNullValue)
    {
        return notNullValue.Value;
    }

    public static implicit operator NotNull<T>(T value)
    {
        return new NotNull<T> { Value = value };
    }
}

Użyłbyś bardzo podobnie do tego samego sposobu, w jaki użyłbyś Nullable<T>, z wyjątkiem tego, aby osiągnąć dokładnie odwrotnie - nie pozwolić null. Oto kilka przykładów:

NotNull<Person> person = null; // throws exception
NotNull<Person> person = new Person(); // OK
NotNull<Person> person = GetPerson(); // throws exception if GetPerson() returns null

NotNull<T> jest implicite odlewany do i z T, więc możesz go używać wszędzie, gdzie go potrzebujesz. Na przykład możesz przekazać obiekt {[12] } do metody, która pobiera NotNull<Person>:

Person person = new Person { Name = "John" };
WriteName(person);

public static void WriteName(NotNull<Person> person)
{
    Console.WriteLine(person.Value.Name);
}

Jak widać powyżej, podobnie jak w przypadku nullable, uzyskasz dostęp do wartości bazowej poprzez właściwość Value. Alternatywnie, możesz użyć jawnego lub niejawnego cast, możesz zobaczyć przykład z wartością zwracaną poniżej:

Person person = GetPerson();

public static NotNull<Person> GetPerson()
{
    return new Person { Name = "John" };
}

Lub można go nawet użyć, gdy metoda zwraca po prostu T (w tym przypadku Person), wykonując Obsada Na przykład następujący kod będzie tak samo jak powyższy kod:

Person person = (NotNull<Person>)GetPerson();

public static Person GetPerson()
{
    return new Person { Name = "John" };
}

Połącz z rozszerzeniem

Połącz NotNull<T> z metodą rozszerzenia, a możesz pokryć jeszcze więcej sytuacji. Oto przykład jak może wyglądać metoda rozszerzenia:

[System.Diagnostics.DebuggerNonUserCode]
public static class NotNullExtension
{
    public static T NotNull<T>(this T @this) where T : class
    {
        if (@this == null)
        {
            throw new Exception("null value not allowed");
        }

        return @this;
    }
}

A oto przykład, jak można go użyć:

var person = GetPerson().NotNull();

GitHub

W celach informacyjnych udostępniłem powyższy kod na Githubie, możesz go znaleźć at:

Https://github.com/luisperezphd/NotNull

Możesz użyć null wzorzec obiektu i Specjalny wzorzec przypadku w przypadkach, gdy istnieje uzasadniony obiekt, który może zastąpić null.

W przypadkach, gdy taki obiekt nie może być skonstruowany, ponieważ po prostu nie ma sposobu na zaimplementowanie jego obowiązkowych operacji, można polegać na pustych kolekcjach, np. w Map-Reduce Queries.

Innym rozwiązaniem jest opcja functional type , która jest zbiorem z zerowymi lub jednymi elementami. W ten sposób, będziesz miał możliwość pominięcia operacji, której nie można wykonać.

Są to opcje, które mogą pomóc w pisaniu kodu bez żadnych referencji null i sprawdzania null.

Narzędzia, które mogą pomóc

Istnieje również kilka bibliotek, które mogą pomóc. Microsoft Code Contracts został wymieniony powyżej.

Niektóre inne narzędzia obejmują Resharper , które mogą dostarczać ostrzeżenia podczas pisania kodu, zwłaszcza jeśli używasz ich atrybutu: NotNullAttribute

Istnieje również PostSharp , który pozwoli Ci używać takich atrybutów jak:

public void DoSometing([NotNull] obj)

Robiąc to i czyniąc PostSharp częścią twojego proces budowania obj będzie sprawdzany pod kątem null w czasie wykonywania. Zobacz: PostSharp null check

Projekt Fody code-weaving ma wtyczkę do implementacji null guards.

NullReferenceException można wyświetlić, gdy metoda nie została znaleziona w złożeniu, dla ex m0=mi.GetType ().GetMethod ("TellChildToBeQuiet"), gdzie montaż jest SportsMiniCar, mi jest instancją minivana, a TellChildToBeQuiet jest metodą w montażu. Możemy tego uniknąć widząc, że wersja assembly 2.0.0.0 zawierająca powyższą metodę jest umieszczona w GAC. przykład: wywołanie metod z parametrami` '

enter code here

using System;
using System.Rwflection;
using System.IO;
using Carlibraries;
namespace LateBinding
{
public class program
{
   static void Main(syring[] args)
   {
         Assembly a=null;
         try
         {
              a=Assembly.Load("Carlibraries");
         }
         catch(FileNotFoundException e)
         {
               Console.Writeline(e.Message);
               Console.ReadLine();
               return;
         }
         Type miniVan=a.GetType("Carlibraries.MiniVan");
         MiniVan mi=new MiniVan();
         mi.TellChildToBeQuiet("sonu",4);
         Console.ReadLine();
       }
   }
   }

Pamiętaj o aktualizacji zestawu MiniSportsCar z TellChildToBeQuiet (string ChildName,int count)