Czy zwracanie wartości null jest złym projektem? [Zamknięte]

Słyszałem głosy mówiące, że sprawdzanie zwróconej wartości null z metod jest złym projektem. Chciałbym poznać kilka powodów takiego stanu rzeczy.

pseudo kod:

variable x = object.method()
if (x is null) do something

Powodem, dla którego nie zwraca się wartości null, jest to, że nie trzeba go sprawdzać, a zatem kod nie musi podążać inną ścieżką w oparciu o zwracaną wartość. Możesz sprawdzić wzorzec obiektu zerowego, który zawiera więcej informacji na ten temat.

Na przykład, gdybym miał zdefiniować metodę w Javie, która zwraca Collection, zazwyczaj wolałbym zwrócić pustą kolekcję (tj. Collections.emptyList()) Zamiast null, ponieważ oznacza to, że mój kod klienta jest czystszy; na przykład

Collection<? extends Item> c = getItems(); // Will never return null.

for (Item item : c) { // Will not enter the loop if c is empty.
  // Process item.
}

... który jest czystszy niż:

Collection<? extends Item> c = getItems(); // Could potentially return null.

// Two possible code paths now so harder to test.
if (c != null) {
  for (Item item : c) {
    // Process item.
  }
}

Oto powód.

W Clean Code Roberta Martina pisze, że zwracanie wartości null jest złym projektem, gdy można zamiast tego zwrócić, powiedzmy, pustą tablicę. Skoro oczekiwanym wynikiem jest tablica, dlaczego nie? Umożliwi ci to iterację wyniku bez żadnych dodatkowych warunków. Jeśli jest to liczba całkowita, może wystarczy 0, jeśli jest to hash, pusty hash. itp.

Założeniem jest, aby nie zmuszać wywołującego kodu do natychmiastowego rozwiązywania problemów. Kod telefoniczny może nie chcieć się nimi przejmować. Dlatego też w wielu przypadkach wyjątki są lepsze niż zero.

Dobre zastosowania zwracania wartości null:

• Jeśli null jest prawidłowym wynikiem funkcjonalnym , na przykład: FindFirstObjectThatNeedsProcessing () może zwrócić wartość null, jeśli nie zostanie znaleziony, a wywołujący powinien odpowiednio sprawdzić.

Złe zastosowania: próba zastąpienia lub ukrycia wyjątkowych sytuacji, takich jak:

• catch (...) and return null
• Inicjalizacja zależności interfejsu API nie powiodła się
• Brak miejsca na dysku
• Nieprawidłowe parametry wejściowe (błąd programowania, dane wejściowe muszą zostać oczyszczone przez dzwoniącego)
• itp

W takich przypadkach zgłoszenie wyjątku jest bardziej odpowiednie, ponieważ:

• Zwracana wartość null nie zawiera żadnych znaczących informacji o błędzie
• Bezpośredni rozmówca najprawdopodobniej nie może obsłużyć warunku błędu
• Nie ma gwarancji, że dzwoniący sprawdza wyniki zerowe

Jednak wyjątków nie należy używać do obsługi normalnych warunków działania programu, takich jak:

• Nieprawidłowa nazwa użytkownika / hasło (lub jakiekolwiek dane wprowadzone przez użytkownika)
• Łamanie pętli lub jako nielokalne gotówki

Tak, zwracanie wartości NULL to straszny projekt w świecie zorientowanym obiektowo. Krótko mówiąc, użycie NULL prowadzi do:

• obsługa błędów ad hoc (zamiast wyjątków)
• niejednoznaczna semantyczna
• powolny zamiast szybkiego awarii
• myślenie komputerowe zamiast myślenia przedmiotowego
• zmienne i niekompletne obiekty

Sprawdź ten post na blogu, aby uzyskać szczegółowe wyjaśnienie: http://www.yegor256.com/2014/05/13/why-null-is-bad.html . Więcej w mojej książce Elegant Objects , Rozdział 4.1.

Kto powiedział, że to zły projekt?

Sprawdzanie wartości null jest powszechną praktyką, a nawet zalecaną, w przeciwnym razie wszędzie ryzykujesz NullReferenceExceptions. Lepiej jest obsługiwać błąd z wdziękiem niż rzucać wyjątki, gdy nie jest to konieczne.

Na podstawie tego, co powiedziałeś do tej pory, myślę, że nie ma wystarczających informacji.

Zwracanie wartości null z metody CreateWidget () wydaje się złe.

Zwracanie wartości null z metody FindFooInBar () wydaje się w porządku.

Jego wynalazca mówi, że to błąd wart miliardy dolarów!

To zależy od języka, którego używasz. Jeśli pracujesz w języku takim jak C #, w którym idiomatycznym sposobem wskazania braku wartości jest zwrócenie wartości null, to zwrócenie wartości null jest dobrym projektem, jeśli nie masz wartości. Alternatywnie, w językach takich jak Haskell, które idiomatycznie używają monady Może w tym przypadku, zwrócenie wartości null byłoby złym projektem (gdyby było to w ogóle możliwe).

Jeśli przeczytasz wszystkie odpowiedzi, stanie się jasne, że odpowiedź na to pytanie zależy od rodzaju metody.

Po pierwsze, gdy dzieje się coś wyjątkowego (IOproblem itp.), Logicznie wyjątki są generowane. Kiedy dokładnie coś jest wyjątkowe, to prawdopodobnie jest coś na inny temat.

Ilekroć metoda prawdopodobnie nie przyniesie żadnych wyników, istnieją dwie kategorie:

• Jeśli możliwe jest zwrócenie wartości neutralnej, zrób to .
  Puste enumrable, stringi itp. Są dobrymi przykładami
• Jeśli taka neutralna wartość nie istnieje, należy zwrócić null .
  Jak wspomniano, zakłada się, że metoda prawdopodobnie nie daje wyniku, więc nie jest wyjątkowa, dlatego nie należy zgłaszać wyjątku. Wartość neutralna nie jest możliwa (na przykład: 0 nie jest szczególnie neutralnym wynikiem, w zależności od programu)

Dopóki nie mamy oficjalnego sposobu na oznaczenie, że funkcja może zwracać wartość null lub nie może, staram się zastosować konwencję nazewnictwa, aby to oznaczyć.
Podobnie jak w przypadku konwencji Try Something () dla metod, w przypadku których oczekuje się niepowodzenia, często nazywam moje metody Safe Something (), gdy metoda zwraca neutralny wynik zamiast null.

Nie jestem jeszcze w pełni w porządku z nazwą, ale nie mogłem wymyślić nic lepszego. Więc na razie z tym biegam.

Mam konwencję w tej dziedzinie, która dobrze mi służyła

W przypadku zapytań o pojedynczy przedmiot:

• Create...zwraca nową instancję lub zgłasza
• Get...zwraca oczekiwaną istniejącą instancję lub zgłasza
• GetOrCreate...zwraca istniejące wystąpienie lub nowe wystąpienie, jeśli żadne nie istnieje lub zgłasza
• Find...zwraca istniejące wystąpienie, jeśli istnieje, lubnull

W przypadku zapytań dotyczących kolekcji:

• Get... zawsze zwraca kolekcję, która jest pusta, jeśli nie znaleziono pasujących [1] elementów

[1] z określonymi kryteriami, jawnymi lub niejawnymi, podanymi w nazwie funkcji lub jako parametry.

Wyjątki dotyczą wyjątkowych okoliczności.

Jeśli celem funkcji jest znalezienie atrybutu skojarzonego z danym obiektem, a ten obiekt nie ma takiego atrybutu, może być właściwe zwrócenie wartości null. Jeśli obiekt nie istnieje, zgłoszenie wyjątku może być bardziej odpowiednie. Jeśli funkcja ma zwracać listę atrybutów, a nie ma żadnych do zwrócenia, zwrócenie pustej listy ma sens - zwracasz wszystkie atrybuty zerowe.

Można zwrócić wartość null, jeśli ma to jakieś znaczenie:

public String getEmployeeName(int id){ ..}

W takim przypadku sensowne jest zwrócenie wartości null, jeśli identyfikator nie odpowiada istniejącej encji, ponieważ pozwala to odróżnić przypadek, w którym nie znaleziono dopasowania, od uzasadnionego błędu.

Ludzie mogą pomyśleć, że jest to złe, ponieważ może być nadużywane jako „specjalna” wartość zwracana, która wskazuje stan błędu, co nie jest zbyt dobre, trochę jak zwracanie kodów błędów z funkcji, ale jest mylące, ponieważ użytkownik musi sprawdzić zwrot dla null, zamiast łapać odpowiednie wyjątki, np

public Integer getId(...){
   try{ ... ; return id; }
   catch(Exception e){ return null;}
}

Niekoniecznie jest to zły projekt - tak jak w przypadku wielu decyzji projektowych, to zależy.

Jeśli wynik metody jest czymś, co nie miałoby dobrego wyniku przy normalnym użyciu, zwrócenie wartości null jest w porządku:

object x = GetObjectFromCache();   // return null if it's not in the cache

Jeśli naprawdę zawsze powinien występować wynik inny niż zerowy, może być lepiej zgłosić wyjątek:

try {
   Controller c = GetController();    // the controller object is central to 
                                      //   the application. If we don't get one, 
                                      //   we're fubar

   // it's likely that it's OK to not have the try/catch since you won't 
   // be able to really handle the problem here
}
catch /* ... */ {
}

W niektórych scenariuszach chcesz zauważyć awarię, gdy tylko to nastąpi.

Sprawdzanie wartości NULL i nie potwierdzanie (w przypadku błędów programisty) lub zgłaszanie (w przypadku błędów użytkownika lub wywołującego) w przypadku niepowodzenia może oznaczać, że późniejsze awarie są trudniejsze do wyśledzenia, ponieważ nie znaleziono oryginalnego dziwnego przypadku.

Ponadto ignorowanie błędów może prowadzić do exploitów bezpieczeństwa. Być może brak wartości wynikał z faktu, że bufor został nadpisany lub tym podobne. Teraz nie ulegasz awarii, co oznacza, że ​​exploiter ma szansę wykonać w Twoim kodzie.

Jakie widzisz alternatywy zwracania wartości null?

Widzę dwa przypadki:

• findAnItem (id). Co należy zrobić, jeśli element nie zostanie znaleziony

W tym przypadku moglibyśmy: Zwrócić Null lub zgłosić (zaznaczony) wyjątek (lub może utworzyć element i zwrócić go)

• listItemsMatching (kryteria) co powinien zwrócić, jeśli nic nie zostanie znalezione?

W tym przypadku możemy zwrócić Null, zwrócić pustą listę lub zgłosić wyjątek.

Uważam, że zwrot null może być mniej dobry niż alternatywy, ponieważ wymaga od klienta, aby pamiętać o sprawdzeniu wartości null, zapomnieniu przez programistów i zakodowaniu

x = find();
x.getField();  // bang null pointer exception

W Javie zgłoszenie sprawdzonego wyjątku RecordNotFoundException pozwala kompilatorowi przypomnieć klientowi o zajęciu się wielkością liter.

Uważam, że wyszukiwanie zwracające puste listy może być całkiem wygodne - po prostu zapełnij wyświetlacz całą zawartością listy, och, jest pusta, kod „po prostu działa”.

Czasami zwracanie wartości NULL jest właściwą rzeczą do zrobienia, ale szczególnie, gdy masz do czynienia z sekwencjami różnego rodzaju (tablice, listy, łańcuchy, co-masz-ty), prawdopodobnie lepiej jest zwrócić sekwencję o zerowej długości, ponieważ prowadzi do krótszego i, miejmy nadzieję, bardziej zrozumiałego kodu, nie zajmując się jednak dużo pisaniem po stronie implementującej API.

Spraw, aby wywoływały inną metodę po fakcie, aby dowiedzieć się, czy poprzednie wywołanie było puste. ;-) Hej, to wystarczyło dla JDBC

Podstawową ideą tego wątku jest programowanie defensywne. To znaczy kod przeciwko nieoczekiwanemu. Istnieje szereg różnych odpowiedzi:

Adamski sugeruje przyjrzenie się wzorcowi obiektów zerowych, przy czym ta odpowiedź została zatwierdzona i głosowała za tą sugestią.

Michael Valenty sugeruje również konwencję nazewnictwa, aby powiedzieć deweloperowi, czego można się spodziewać. ZeroConcept sugeruje prawidłowe użycie wyjątku, jeśli jest to powód NULL. I inni.

Jeśli ustalimy „zasadę”, że zawsze chcemy robić programowanie obronne, wtedy zobaczymy, że te sugestie są słuszne.

Ale mamy 2 scenariusze rozwoju.

Zajęcia „autorstwa” programisty: Autor

Klasy „zużyte” przez innego (być może) programistę: programistę

Niezależnie od tego, czy klasa zwraca wartość NULL dla metod zwracających wartość, czy nie, programista będzie musiał sprawdzić, czy obiekt jest prawidłowy.

Jeśli programista nie może tego zrobić, to ta klasa / metoda nie jest deterministyczna. Oznacza to, że jeśli „wywołanie metody” w celu pobrania obiektu nie robi tego, co „ogłasza” (np. GetEmployee), zrywa kontrakt.

Jako autor klasy zawsze chcę być uprzejmy i defensywny (i deterministyczny) podczas tworzenia metody.

Biorąc więc pod uwagę, że należy sprawdzić NULL lub NULL OBJECT (np. Jeśli (pracownik jako NullEmployee.ISVALID)) musi zostać sprawdzony i może się to zdarzyć w przypadku kolekcji pracowników, wówczas podejście zerowe jest lepszym podejściem.

Ale lubię też Michaela Valentego sugestia dotycząca nazwania metody, która MUSI zwrócić wartość null, np. GetEmployeeOrNull.

Autor, który zgłasza wyjątek, usuwa możliwość sprawdzenia poprawności obiektu przez dewelopera, co jest bardzo niekorzystne dla kolekcji obiektów i zmusza programistę do obsługi wyjątków podczas rozgałęziania używanego kodu.

Jako programista korzystający z klasy mam nadzieję, że autor da mi możliwość unikania lub programowania zerowej sytuacji, z którą mogą się spotkać ich klasy / metody.

Więc jako programista mógłbym programować defensywnie przed NULL z metody. Jeśli autor dał mi kontrakt, który zawsze zwraca obiekt (NULL OBJECT zawsze tak robi) i ten obiekt ma metodę / właściwość, za pomocą której można przetestować ważność obiektu, to użyłbym tej metody / właściwości, aby nadal używać obiektu , inaczej obiekt jest nieprawidłowy i nie mogę go użyć.

Podsumowując, autor klasy / metod musi zapewnić mechanizmy, które Programista może wykorzystać w swoim programowaniu obronnym. To znaczy jaśniejszy zamiar metody.

Deweloper powinien zawsze używać programowania obronnego do testowania poprawności obiektów zwróconych z innej klasy / metody.

pozdrowienia

GregJF

Inne opcje to: zwrócenie pewnej wartości, która wskazuje sukces lub nie (lub typ błędu), ale jeśli potrzebujesz tylko wartości logicznej, która wskaże sukces / niepowodzenie, zwracanie wartości zerowej w przypadku niepowodzenia, a obiekt wskazujący na sukces nie będzie być mniej poprawne, a następnie zwraca prawda / fałsz i pobiera obiekt za pomocą parametru.
Innym podejściem byłoby użycie wyjątku do wskazania awarii, ale tutaj - w rzeczywistości jest o wiele więcej głosów, które mówią, że jest to ZŁA praktyka (ponieważ używanie wyjątków może być wygodne, ale ma wiele wad).
Więc osobiście nie widzę nic złego w zwracaniu wartości null jako wskazaniu, że coś poszło nie tak, i sprawdzaniu tego później (aby faktycznie wiedzieć, czy ci się udało, czy nie). Ponadto ślepe myślenie, że twoja metoda nie zwróci wartości NULL, a następnie oprze na niej swój kod, może prowadzić do innych, czasem trudnych do znalezienia, błędów (chociaż w większości przypadków po prostu spowoduje to awarię systemu :), jak będziesz odnosić się do 0x00000000 prędzej czy później).

Niezamierzone funkcje zerowe mogą pojawić się podczas tworzenia złożonych programów i podobnie jak martwy kod, takie zdarzenia wskazują na poważne wady struktur programu.

Funkcja lub metoda o wartości null jest często używana jako domyślne zachowanie funkcji z możliwością przywrócenia lub metody nadpisywalnej w strukturze obiektów.

Null_function @wikipedia

Cóż, to na pewno zależy od celu metody ... Czasami lepszym wyborem byłoby rzucenie wyjątku. Wszystko zależy od przypadku.

Jeśli kod jest taki jak:

command = get_something_to_do()

if command:  # if not Null
    command.execute()

Jeśli masz fikcyjny obiekt, którego metoda execute () nic nie robi i zwracasz to zamiast Null w odpowiednich przypadkach, nie musisz sprawdzać przypadku Null i możesz zamiast tego zrobić:

get_something_to_do().execute()

Tak więc tutaj problem nie dotyczy sprawdzania wartości NULL i wyjątku, ale raczej polega na tym, że wywołujący musi inaczej (w jakikolwiek sposób) obsługiwać specjalne przypadki niezamierzone lub nie.

W moim przypadku musiałem zwrócić Map z metody, a następnie poszukać określonego klucza. Ale jeśli zwrócę pustą mapę, to doprowadzi to do NullPointerException i wtedy nie będzie to zupełnie inne zwracanie wartości null zamiast pustej mapy. Ale począwszy od Java8 mogliśmy używać Optional . To właśnie jest powodem wprowadzenia koncepcji opcjonalnej.

Dzień dobry,

Zwracanie wartości NULL, gdy nie można utworzyć nowego obiektu, jest standardową praktyką w wielu interfejsach API.

Dlaczego do diabła to zły projekt, nie mam pojęcia.

Edycja: Dotyczy to języków, w których nie ma wyjątków, takich jak C, gdzie jest to konwencja od wielu lat.

HTH

`` Avahappy,