Czy nie jest uzasadnione oczekiwanie, że Any () * not * zgłosi wyjątek o wartości zerowej?

Kiedy tworzysz metodę rozszerzenia, możesz oczywiście ją wywołać. nullAle w przeciwieństwie do wywołania metody instancji, wywołanie jej na wartość null nie musi rzucać NullReferenceException-> musisz to sprawdzić i rzucić ręcznie.

W celu wdrożenia metody rozszerzenia Linq Any()Microsoft zdecydował, że powinien rzucić ArgumentNullException( https://github.com/dotnet/corefx/blob/master/src/System.Linq/src/System/Linq/AnyAll.cs ).

Denerwuje mnie to, że muszę pisać if( myCollection != null && myCollection.Any() )

Czy mam rację, jako klient tego kodu, oczekując, że np. ((int[])null).Any()Powinien zwrócić false?

Mam torbę z pięcioma ziemniakami. Czy .Any()w torbie są ziemniaki?

„ Tak ”, mówisz.<= true

Wyjmuję wszystkie ziemniaki i jem. Czy .Any()w torbie są ziemniaki?

„ Nie ”, mówisz.<= false

Całkowicie spalam torbę w ogniu. Czy .Any()w torbie są teraz ziemniaki?

„ Nie ma torby ”.<= ArgumentNullException

Po pierwsze, wygląda na to, że ten kod źródłowy wyrzuci ArgumentNullException, a nie NullReferenceException.

To powiedziawszy, w wielu przypadkach już wiesz, że twoja kolekcja nie ma wartości NULL, ponieważ ten kod jest wywoływany tylko z kodu, który wie, że kolekcja już istnieje, więc nie będziesz musiał często umieszczać w nim kontroli null. Ale jeśli nie wiesz, że istnieje, warto sprawdzić to przed wywołaniem Any().

Czy mam rację, jako klient tego kodu, oczekując, że np. ((int[])null).Any()Powinien zwrócić false?

Tak. Pytanie, na które Any()odpowiedzi brzmi „czy ta kolekcja zawiera jakieś elementy?” Jeśli ten zbiór nie istnieje, samo pytanie jest nonsensowne; nie może ani zawierać ani nie zawierać niczego, ponieważ nie istnieje.

Null oznacza brakujące informacje, a nie brak elementów.

Można rozważyć bardziej ogólnie unikanie wartości null - na przykład użyj jednego z wbudowanych pustych elementów wyliczeniowych do reprezentowania kolekcji bez elementów zamiast wartości null.

Jeśli w niektórych okolicznościach zwracasz wartość null, możesz to zmienić, aby zwrócić pustą kolekcję. (W przeciwnym razie, jeśli znajdziesz wartości zerowe zwrócone przez metody biblioteczne (nie twoje), to niefortunne, i owinąłbym je, aby się znormalizować.)

Zobacz także https://stackoverflow.com/questions/1191919/what-does-linq-return-when-the-results-are-empty

Oprócz składni zerowej warunkowej istnieje jeszcze jedna technika rozwiązania tego problemu: nie pozwól, aby zmienna pozostała null.

Rozważ funkcję, która akceptuje kolekcję jako parametr. Jeśli dla celów funkcji nulli puste są równoważne, możesz upewnić się, że nigdy nie zawiera nullna początku:

public MyResult DoSomething(int a, IEnumerable<string> words)
{
    words = words ?? Enumerable.Empty<string>();

    if (!words.Any())
    {
        ...

Możesz zrobić to samo, pobierając kolekcje z innej metody:

var words = GetWords() ?? Enumerable.Empty<string>();

(Pamiętaj, że w przypadkach, w których masz kontrolę nad funkcją podobną do pustej kolekcji GetWordsi nulljest ona równoważna, lepiej jest po prostu zwrócić pustą kolekcję.)

Teraz możesz wykonać dowolną operację na kolekcji. Jest to szczególnie przydatne, jeśli trzeba wykonać wiele operacji, które zakończyłyby się niepowodzeniem, gdy kolekcja jest null, a w przypadkach, gdy uzyskuje się ten sam wynik przez zapętlenie lub zapytanie pustej listy, pozwoli to ifcałkowicie wyeliminować warunki.

Czy się mylę, jako klient tego kodu, oczekując, że np. ((Int []) null) .Każdy () powinien zwrócić wartość false?

Tak, po prostu dlatego, że jesteś w C #, a to zachowanie jest dobrze zdefiniowane i udokumentowane.

Jeśli tworzysz własną bibliotekę lub używasz innego języka z inną kulturą wyjątków, rozsądniej byłoby oczekiwać fałszu.

Osobiście uważam, że zwrot fałszywy jest bezpieczniejszym podejściem, które sprawia, że ​​twój program jest bardziej niezawodny, ale przynajmniej jest dyskusyjny.

Jeśli denerwują Cię powtarzające się testy zerowe, możesz utworzyć własną metodę rozszerzenia „IsNullOrEmpty ()”, aby utworzyć kopię lustrzaną metody String o tej nazwie i zawinąć zarówno kontrolę zerową, jak i wywołanie .Any () w jedno wywołanie.

W przeciwnym razie rozwiązanie wspomniane przez @ 17 z 26 w komentarzu pod twoim pytaniem jest również krótsze niż metoda „standardowa” i dość zrozumiałe dla każdego, kto zna nową składnię zerową.

if(myCollection?.Any() == true)

Czy się mylę, jako klient tego kodu, oczekując, że np. ((Int []) null) .Każdy () powinien zwrócić wartość false?

Jeśli zastanawiasz się nad oczekiwaniami, musisz pomyśleć o intencjach.

null oznacza coś zupełnie innego niż Enumerable.Empty<T>

Jak wspomniano w odpowiedzi Erika Eidta , istnieje różnica między znaczeniem nulla pustą kolekcją.

Najpierw rzućmy okiem na to, jak mają być używane.

Książka Framework Design Guidelines: Conventions, Idioms and Patterns for Wielokrotnego użytku bibliotek .NET, 2. wydanie, napisane przez architektów Microsoft, Krzysztofa Cwalinę i Brada Abramsa, podaje następującą najlepszą praktykę:

X NIE zwracaj wartości pustych z właściwości kolekcji lub z metod zwracających kolekcje. Zamiast tego zwraca pustą kolekcję lub pustą tablicę.

Rozważ wywołanie metody, która ostatecznie pobiera dane z bazy danych: Jeśli otrzymasz pustą tablicę lub Enumerable.Empty<T>oznacza to po prostu, że Twoja próbka jest pusta, tzn. Twój wynik jest pustym zestawem . Odbieranie nullw tym kontekście oznaczałoby jednak stan błędu .

W tym samym myśleniu, co analogia ziemniaka Dana Wilsona , sensowne jest zadawanie pytań o dane, nawet jeśli jest to pusty zestaw . Ale ma to o wiele mniej sensu, jeśli nie ma zestawu .

Istnieje wiele odpowiedzi wyjaśniających, dlaczego nulli puste są różne, oraz wystarczająca liczba opinii próbujących wyjaśnić, dlaczego należy je traktować inaczej, czy nie. Jednak pytasz:

Czy się mylę, jako klient tego kodu, oczekując, że np. ((Int []) null) .Każdy () powinien zwrócić wartość false?

Jest to całkowicie uzasadnione oczekiwanie . Jesteś jak prawo jak ktoś opowiada o obecnym zachowaniu. Zgadzam się z obecną filozofią wdrażania, ale czynniki napędzające są nie tylko oparte na względach poza kontekstem.

Biorąc pod uwagę, że Any()bez predykatu jest zasadniczo Count() > 0to, czego oczekujesz od tego fragmentu?

List<int> list = null;
if (list.Count > 0) {}

Lub ogólny:

List<int> list = null;
if (list.Foo()) {}

Przypuszczam, że się spodziewasz NullReferenceException.

• Any()jest metodą rozszerzenia, powinna płynnie integrować się z rozszerzonym obiektem, a następnie zgłoszenie wyjątku jest najmniej zaskakującą rzeczą.
• Nie każdy język .NET obsługuje metody rozszerzeń.
• Zawsze możesz zadzwonić Enumerable.Any(null)i tam na pewno się spodziewasz ArgumentNullException. Jest to ta sama metoda i musi być zgodna z - być może - prawie WSZYSTKIM innym w ramach.
• Dostęp do nullobiektu jest błędem programistycznym , środowisko nie powinno wymuszać wartości null jako magicznej wartości . Jeśli użyjesz go w ten sposób, musisz sobie z tym poradzić.
• Jest opiniotwórczy , myślisz w jeden sposób, a ja w inny sposób. Ramy powinny być w jak największym stopniu niedoceniane.
• Jeśli masz szczególny przypadek, musisz być konsekwentny : musisz podejmować coraz bardziej przemyślane decyzje dotyczące wszystkich innych metod rozszerzenia: jeśli Count()wydaje się to łatwa decyzja, Where()nie jest. Co Max()? Zgłasza wyjątek dla listy PUSTEJ, czy nie powinno to również wyrzucić dla nulljednego?

To, co projektanci bibliotek zrobili przed LINQ, polegało na wprowadzeniu jawnych metod, gdy nulljest to prawidłowa wartość (na przykład String.IsNullOrEmpty()), wtedy MUSI być spójne z istniejącą filozofią projektowania . To powiedziawszy, nawet jeśli dość proste do napisania, dwie metody EmptyIfNull()i EmptyOrNull()mogą się przydać.

Jim powinien zostawiać ziemniaki w każdej torbie. W przeciwnym razie go zabiję.

Jim ma worek z pięcioma ziemniakami. Czy .Any()w torbie są ziemniaki?

„Tak”, mówisz. <= prawda

Ok, więc tym razem Jim żyje.

Jim bierze wszystkie ziemniaki i je je. Czy w torbie są jakieś. () Ziemniaki?

„Nie”, mówisz. <= fałsz

Czas zabić Jima.

Jim całkowicie spala torbę w ogniu. Czy w torbie są teraz jakieś. () Ziemniaki?

„Nie ma torby”. <= ArgumentNullException

Czy Jim powinien żyć czy umrzeć? Nie spodziewaliśmy się tego, więc potrzebuję orzeczenia. Czy pozwolenie Jimowi na ucieczkę to błąd, czy nie?

Możesz użyć adnotacji, aby zasygnalizować, że nie znosisz w ten sposób żadnych zerowych shenaniganów.

public bool Any( [NotNull] List bag ) 

Ale Twój łańcuch narzędzi musi to obsługiwać. Co oznacza, że ​​prawdopodobnie nadal będziesz pisać czeki.

Jeśli tak bardzo Ci to przeszkadza, proponuję prostą metodę rozszerzenia.

static public IEnumerable<T> NullToEmpty<T>(this IEnumerable<T> source)
{
    return (source == null) ? Enumerable.Empty<T>() : source;
}

Teraz możesz to zrobić:

List<string> list = null;
var flag = list.NullToEmpty().Any( s => s == "Foo" );

... a flaga zostanie ustawiona na false.

To jest pytanie dotyczące metod rozszerzenia C # i ich filozofii projektowania, więc myślę, że najlepszym sposobem na odpowiedź na to pytanie jest zacytowanie dokumentacji MSDN na temat metod rozszerzenia :

Metody rozszerzeń umożliwiają „dodawanie” metod do istniejących typów bez tworzenia nowego typu pochodnego, ponownej kompilacji lub innego modyfikowania oryginalnego typu. Metody rozszerzeń są specjalnym rodzajem metod statycznych, ale są wywoływane tak, jakby były metodami instancji typu rozszerzonego. W przypadku kodu klienta napisanego w C #, F # i Visual Basic nie ma widocznej różnicy między wywołaniem metody rozszerzenia a metodami, które są faktycznie zdefiniowane w typie.

…

Ogólnie zalecamy oszczędne wdrażanie metod rozszerzeń i tylko wtedy, gdy jest to konieczne. O ile to możliwe, kod klienta, który musi rozszerzyć istniejący typ, powinien to zrobić, tworząc nowy typ pochodzący z istniejącego typu. Aby uzyskać więcej informacji, zobacz Dziedziczenie.

Korzystając z metody rozszerzenia do rozszerzenia typu, którego kodu źródłowego nie można zmienić, istnieje ryzyko, że zmiana w implementacji typu spowoduje uszkodzenie metody rozszerzenia.

Jeśli implementujesz metody rozszerzenia dla danego typu, pamiętaj o następujących punktach:

• Metoda rozszerzenia nigdy nie zostanie wywołana, jeśli ma taki sam podpis jak metoda zdefiniowana w typie.
• Metody rozszerzeń są wprowadzane w zakres na poziomie przestrzeni nazw. Na przykład, jeśli masz wiele klas statycznych, które zawierają metody rozszerzeń w pojedynczej nazwanej przestrzeni nazw Extensions, wszystkie one zostaną objęte zakresem using Extensions;dyrektywy.

Podsumowując, metody rozszerzeń służą do dodawania metod instancji do określonego typu, nawet jeśli programiści nie mogą tego zrobić bezpośrednio. A ponieważ metody instancji zawsze zastępują metody rozszerzeń, jeśli są obecne (jeśli są wywoływane przy użyciu składni metody instancji), należy to zrobić tylko wtedy, gdy nie można bezpośrednio dodać metody lub rozszerzyć klasy. *

Innymi słowy, metoda rozszerzenia powinna działać tak samo, jak metoda instancji, ponieważ może być w końcu metodą instancji stworzoną przez jakiegoś klienta. A ponieważ metoda instancji powinna rzucić, jeśli wywoływany jest obiekt null, podobnie jak metoda rozszerzenia.

* Na marginesie, jest to dokładnie taka sytuacja, że projektanci z LINQ do czynienia: gdy C # 3.0 został wydany, były już miliony klientów, którzy używali System.Collections.IEnumerablei System.Collections.Generic.IEnumerable<T>, zarówno w swoich zbiorach i foreachpętle. Klasy te zwrócone IEnumeratorprzedmioty, które miał tylko dwie metody Currenti MoveNext, więc dodanie dodatkowych wymaganych metod przykład, takie jak Count, Anyitd byłoby złamanie tych milionów klientów. Tak więc, w celu dostarczenia tej funkcji (zwłaszcza, że to może być realizowane w warunkach Currenti MoveNextze względną łatwością), wydali go jako metod rozszerzeń, które mogą być stosowane do każdego obecnie istniejącychIEnumerablewystąpienie i może być również zaimplementowane przez klasy w bardziej wydajny sposób. Gdyby projektanci C # zdecydowali się wydać LINQ pierwszego dnia, byłby on dostarczony jako metoda instancji IEnumerablei prawdopodobnie zaprojektowaliby jakiś system zapewniający domyślne implementacje interfejsu tych metod.

Myślę, że istotną kwestią jest to, że zwracając wartość false zamiast zgłaszania wyjątku, zaciemniasz informacje, które mogą być istotne dla przyszłych czytelników / modyfikatorów twojego kodu.

Jeśli możliwe jest, aby lista była pusta, sugerowałbym, aby mieć do tego osobną ścieżkę logiczną, ponieważ w przeciwnym razie ktoś może dodać logikę opartą na liście (np. Dodać) do else {} twojego if, w wyniku czego niechciany wyjątek, którego nie mieli powodu przewidzieć.

Czytelność i łatwość konserwacji przeważają „muszę napisać dodatkowy warunek” za każdym razem.

Zasadniczo piszę większość mojego kodu, aby założyć, że dzwoniący jest odpowiedzialny za to, że nie przekazuje mi zerowych danych, głównie z powodów opisanych w powiedz „ nie” zeru (i innym podobnym postom). Pojęcie wartości null często nie jest dobrze rozumiane iz tego powodu wskazane jest zainicjowanie zmiennych przed czasem, o ile jest to praktyczne. Zakładając, że pracujesz z rozsądnym API, najlepiej nie powinieneś nigdy odzyskiwać wartości zerowej, więc nigdy nie powinieneś sprawdzać, czy jest pusta. Punkt zerowy, jak stwierdzono w innych odpowiedziach, to upewnienie się, że masz prawidłowy obiekt (np. „Torbę”) do pracy przed kontynuowaniem. To nie jest cecha języka Any, ale funkcja językasamo. Nie można wykonać większości operacji na obiekcie zerowym, ponieważ on nie istnieje. To tak, jakby poprosić cię, abyś pojechał do sklepu w moim samochodzie, z wyjątkiem tego, że nie posiadam samochodu, więc nie możesz użyć mojego samochodu, aby pojechać do sklepu. Bezsensowne jest wykonywanie operacji na czymś, co dosłownie nie istnieje.

Istnieją praktyczne przypadki używania wartości zerowej, na przykład gdy dosłownie nie masz wymaganych informacji (np. Gdybym zapytał cię, jaki jest mój wiek, najbardziej prawdopodobnym wyborem, na który możesz odpowiedzieć w tym momencie, jest „nie wiem ”, co jest wartością zerową). Jednak w większości przypadków powinieneś przynajmniej wiedzieć, czy twoje zmienne zostały zainicjowane czy nie. A jeśli nie, to zalecam zaostrzenie kodu. Pierwszą rzeczą, którą robię w dowolnym programie lub funkcji, jest zainicjowanie wartości przed jej użyciem. Rzadko muszę sprawdzać wartości null, ponieważ mogę zagwarantować, że moje zmienne nie mają wartości null. Dobrym nawykiem jest wchodzenie w to, a im częściej pamiętasz, aby zainicjować zmienne, tym rzadziej musisz sprawdzać, czy nie ma wartości null.