Czy metoda pobierania powinna zwracać "null" lub rzucać wyjątek, gdy nie może wygenerować zwracanej wartości? [zamknięte]

Wyrzuć wyjątek tylko wtedy, gdy naprawdę jest to błąd. Jeśli oczekuje się, że obiekt nie istnieje, zwraca wartość null.

W Przeciwnym Razie jest to kwestia preferencji.

Jako ogólna zasada, jeśli metoda powinna zawsze zwracać obiekt, to przejdź z wyjątkiem. Jeśli przewidujesz okazjonalne null i chcesz obsłużyć go w określony sposób, idź z null.

Cokolwiek robisz, zdecydowanie odradzam trzecią opcję: zwracanie ciągu z napisem "WTF".

Jeśli null nigdy nie wskazuje błędu, po prostu zwróć null.

Jeśli null jest zawsze błędem, wyrzuć wyjątek.

Jeśli null jest czasem wyjątkiem, koduj dwie procedury. Jedna z funkcji rzuca wyjątek, a druga jest boolowską funkcją testową, która zwraca obiekt w parametrze wyjściowym, a funkcja zwraca false, jeśli obiekt nie został znaleziony.

Więc gdy null jest error you just write

object o = FindObject();

Gdy null nie jest błędem możesz zakodować coś w stylu

if (TryFindObject(out object o)
  // Do something with o
else
  // o was not found

Chciałem tylko podsumować wspomniane wcześniej opcje, wrzucić kilka nowych:

1. return null
2. throw an Exception
3. Użyj wzorca obiektu null
4. podaj parametr boolean do metody, aby wywołujący mógł wybrać, czy chce, abyś wyrzucił wyjątek
5. podaj dodatkowy parametr, aby wywołujący mógł ustawić wartość, którą otrzyma z powrotem, jeśli nie zostanie znaleziona żadna wartość

Lub możesz połączyć te opcje:

Podaj kilka przeciążone wersje gettera, więc rozmówca może zdecydować, w którą stronę iść. W większości przypadków tylko pierwszy ma implementację algorytmu wyszukiwania, a pozostałe po prostu owijają się wokół pierwszego:

Object findObjectOrNull(String key);
Object findObjectOrThrow(String key) throws SomeException;
Object findObjectOrCreate(String key, SomeClass dataNeededToCreateNewObject);
Object findObjectOrDefault(String key, Object defaultReturnValue);

Nawet jeśli zdecydujesz się dostarczyć tylko jedną implementację, możesz użyć konwencji nazewnictwa, takiej jak ta, aby wyjaśnić swoją umowę, a to pomaga, jeśli kiedykolwiek zdecydujesz się dodać inne implementacje, jak również.

Użyj wzorca obiektu null lub wyrzuć wyjątek.

Być zgodne z używanymi API.

Zalety wyrzucenia wyjątku:

1. / Align = "center" bgcolor = "# e0ffe0 " / cesarz chin / / align = center / Sprawdzenie czy null wstrzykuje warunkową gałąź, która jest natywnie obsługiwana przez try / catch. Sprawdzanie null nie wskazuje na to, czego szukasz - Czy sprawdzasz null, ponieważ szukasz błędu, którego się spodziewasz, czy też sprawdzasz null, aby nie przekazywać go dalej na downchain?
2. usuwa niejasności co oznacza "null". jest null reprezentuje błąd lub jest null co jest faktycznie przechowywane w wartości? Trudno powiedzieć, kiedy masz tylko jedną rzecz, na której możesz oprzeć tę determinację.
3. Poprawiono spójność między zachowaniem metod w aplikacji. wyjątki są zazwyczaj ujawniane w podpisach metod, więc możesz lepiej zrozumieć, w jakich przypadkach brzegowych metody są używane na koncie aplikacji i na jakie informacje aplikacja może reagować w przewidywalny sposób.

Więcej Wyjaśnienie z przykładami, patrz: http://metatations.com/2011/11/17/returning-null-vs-throwing-an-exception/

To zależy czy twój język i Kod Promuje: LBYL (look before you leap) lub EAFP (easier to ask forgiveness than permission)

LBYL mówi, że powinieneś sprawdzić wartości (więc zwróć null)
EAFP mówi, aby po prostu spróbować operacji i sprawdzić, czy się nie powiedzie (wyrzuć wyjątek)

Choć zgadzam się z powyższym.. wyjątki powinny być używane dla warunków wyjątkowych/błędów, a zwracanie null jest najlepsze podczas korzystania z sprawdzeń.

EAFP vs. LBYL w Pythonie:
http://mail.python.org/pipermail/python-list/2003-May/205182.html ( Web Archive )

Po prostu zadaj sobie pytanie: "czy to wyjątkowy przypadek, że obiekt nie został znaleziony"? Jeśli oczekuje się, że stanie się to w normalnym toku programu, prawdopodobnie nie powinieneś podnosić wyjątku(ponieważ nie jest to wyjątkowe zachowanie).

Wersja skrócona: używaj WYJĄTKÓW do obsługi wyjątkowych zachowań, a nie do obsługi normalnego przepływu sterowania w programie.

-Alan.

Wyjątki są związane z projektem według umowy.

Interfejs obiektu jest w rzeczywistości umową między dwoma obiektami, dzwoniący musi spełnić umowę, w przeciwnym razie odbiorca może po prostu zawieść z wyjątkiem. Możliwe są dwa kontrakty

1) wszystkie dane wejściowe metoda jest poprawna, w takim przypadku należy zwrócić null, gdy obiekt nie został znaleziony.

2) tylko niektóre dane wejściowe są ważne, tj. to, co daje znaleziony obiekt. W takim przypadku musisz zaoferować drugą metodę, która pozwala rozmówcy określić, czy jego dane wejściowe będą poprawne. Na przykład

is_present(key)
find(key) throws Exception

Jeśli podasz obie metody drugiej umowy, możesz rzucić wyjątek, bo nic nie znaleziono!

Wolę po prostu zwracać null i polegać na tym, że rozmówca odpowiednio sobie z tym poradzi. Wyjątkiem (z braku lepszego słowa) Jest, jeśli jestem absolutnie 'pewien', że ta metoda zwróci obiekt. W takim przypadku porażka jest wyjątkowym powinien i powinien rzucić.

Zależy od tego, co to znaczy, że obiekt nie został znaleziony.

Jeśli jest to normalny stan rzeczy, to zwróć null. To jest coś, co może się zdarzyć raz na jakiś czas, a dzwoniący powinni to sprawdzić.

Jeśli jest to błąd, następnie wyrzuć wyjątek, wywołujący powinni zdecydować, co zrobić z warunkiem błędu brakującego obiektu.

Ostatecznie albo zadziała, chociaż większość ludzi ogólnie uważa, że dobrą praktyką jest używanie WYJĄTKÓW tylko wtedy, gdy coś, stało się coś wyjątkowego.

Oto jeszcze kilka propozycji.

Jeśli zwracasz kolekcję, unikaj zwracania null, zwróć pustą kolekcję, która ułatwia obliczanie bez sprawdzania null.

Kilka API. NET używa wzorca parametru thrownOnError, który daje wywołującemu wybór, czy jest to naprawdę wyjątkowa sytuacja, czy nie, jeśli obiekt nie został znaleziony. Typ.GetType jest tego przykładem. Innym wspólnym wzorem z BCL jest wzór TryGet, gdzie zwracana jest wartość logiczna, a wartość jest przekazywana przez parametr wyjściowy.

Można również rozważyć wzorzec obiektu Null w pewnych okolicznościach, który może być albo wersją domyślną, albo wersją bez zachowania. Kluczem jest unikanie sprawdzania null w całej bazie kodu. Zobacz tutaj, aby uzyskać więcej informacji http://geekswithblogs.net/dsellers/archive/2006/09/08/90656.aspx

W niektórych funkcjach dodaję parametr:

..., bool verify = true)

True oznacza rzut, false oznacza zwracanie wartości zwracanej przez błąd. W ten sposób ten, kto używa tej funkcji, ma obie opcje. Wartość domyślna powinna być prawdziwa, z korzyścią dla tych, którzy zapominają o obsłudze błędów.

Zwraca wartość null zamiast rzucania wyjątku i wyraźnie dokumentuje możliwość zwrócenia wartości Null w dokumentacji API. Jeśli kod wywołujący nie honoruje API i sprawdza, czy nie ma przypadku null, najprawdopodobniej i tak spowoduje to jakiś "wyjątek wskaźnika null":)

W C++, mogę myśleć o 3 różnych smakach konfigurowania metody, która znajduje obiekt.

Opcja A

Object *findObject(Key &key);

Zwraca null, gdy nie można znaleźć obiektu. Ładnie i prosto. Wybrałbym ten. Alternatywne podejścia poniżej są dla ludzi, którzy nie nienawidzą out-params.

Opcja B

void findObject(Key &key, Object &found);

Przekazuje odniesienie do zmiennej, która będzie odbierała obiekt. Metoda wyrzuciła wyjątek, gdy nie można znaleźć obiektu. Ta konwencja jest prawdopodobnie bardziej odpowiednia, jeśli nie oczekuje się, że obiekt nie zostanie znaleziony - dlatego rzucasz wyjątek, aby oznaczać, że jest to nieoczekiwany przypadek.

Opcja C

bool findObject(Key &key, Object &found);

Metoda zwraca false, gdy nie można znaleźć obiektu. Zaletą tej opcji nad opcją A jest to, że możesz sprawdzić przypadek błędu w jednym jasnym kroku:

if (!findObject(myKey, myObj)) { ...

Odnosząc się tylko do przypadku, w którym null nie jest uważane za wyjątkowe zachowanie jestem zdecydowanie za metodą try, jest jasne, nie ma potrzeby "czytać książkę" lub "patrzeć, zanim skoczysz", jak zostało powiedziane tutaj

Więc zasadniczo:

bool TryFindObject(RequestParam request, out ResponseParam response)

A to oznacza, że kod użytkownika będzie również jasny

...
if(TryFindObject(request, out response)
{
  handleSuccess(response)
}
else
{
  handleFailure()
}
...

Jeśli jest ważne, aby kod klienta znał różnicę między found I not found i ma to być rutynowe zachowanie, najlepiej zwrócić null. Kod klienta może wtedy zdecydować, co zrobić.

Generalnie powinno zwracać null. Kod wywołujący metodę powinien zdecydować, czy wyrzucić wyjątek, czy spróbować czegoś innego.

Lub zwróć opcję

Opcja jest w zasadzie klasą kontenera, która zmusza klienta do obsługi skrzynek. Scala ma taką koncepcję, poszukaj jej API.

Wtedy masz metody takie jak t getOrElse (t valueIfNull) na tym obiekcie thet albo zwraca znaleziony obiekt, albo allternative specyfiki klienta.

Preferuj zwracanie null --

Jeśli wywołujący używa go bez sprawdzania, wyjątek i tak się tam dzieje.

Jeśli rozmówca naprawdę go nie używa, Nie opodatkuj go try/catch blok

Niestety JDK jest niespójne, jeśli próbujesz uzyskać dostęp do nieistniejącego klucza w resource bundle, dostajesz not found exception, a gdy żądasz wartości z map, dostajesz null, jeśli nie istnieje. Więc chciałbym zmienić odpowiedź zwycięzcy na następujące, jeśli znaleziona wartość może być null, następnie podnieść wyjątek, gdy nie jest znaleziony, w przeciwnym razie zwracają null. Więc postępuj zgodnie z regułą z jednym wyjątkiem, jeśli chcesz wiedzieć, dlaczego wartość nie została znaleziona, to zawsze podnoś wyjątek, lub..

Tak długo, jak ma zwracać odniesienie do obiektu, zwracanie NULL powinno być dobre.

Jeśli jednak zwraca całą cholerną rzecz (jak w C++, jeśli robisz: 'return blah;' zamiast 'return &blah;' (lub 'blah' jest wskaźnikiem), to nie możesz zwrócić NULL, ponieważ nie jest typu 'object'. W takim przypadku rzucenie wyjątku lub zwrócenie pustego obiektu, który nie ma ustawionej flagi sukcesu, jest sposobem podejścia do problemu.

Nie sądzę, że ktoś wspomniał o narzutach w obsłudze WYJĄTKÓW-wymaga dodatkowych zasobów, aby załadować i przetworzyć wyjątek, więc chyba że jest to prawdziwe zabijanie aplikacji lub zatrzymanie procesu (pójście do przodu spowoduje więcej szkody niż pożytku), zdecydowałbym się na przekazanie wartości, którą środowisko wywołujące może zinterpretować tak, jak uzna to za stosowne.

Zgadzam się z tym, co tutaj wydaje się być konsensusem (zwróć null, jeśli "not found" jest normalnym możliwym wynikiem, lub wyrzuć wyjątek, jeśli semantyka sytuacji wymaga, aby obiekt zawsze był znaleziony).

Istnieje jednak trzecia możliwość, która może mieć sens w zależności od konkretnej sytuacji. Twoja metoda może zwrócić jakiś domyślny obiekt w stanie "not found", dzięki czemu kod wywołujący może być pewny, że zawsze otrzyma poprawny obiekt bez potrzeba sprawdzania null lub wyłapywania WYJĄTKÓW.

Zwraca null, wyjątki są dokładnie takie: coś, co robi twój kod, czego nie oczekuje.

Wyjątkami powinny być wyjątkowe . Return NULL jeśli poprawne jest zwrócenie null .

Jeśli metoda zwraca kolekcję, to zwraca pustą kolekcję (jak sayed powyżej). Ale proszę nie zbiórki.EMPTY_LIST czy coś takiego! (w przypadku Javy)

Jeśli metoda pobiera pojedynczy obiekt, to masz kilka opcji.

1. jeśli metoda zawsze powinna znaleźć wynik i jest to prawdziwy wyjątek, aby nie znaleźć obiektu, powinieneś rzucić wyjątek (w języku Java: please an uncheck Exception)
2. (tylko Java), jeśli można tolerować, że metoda rzuca zaznaczony wyjątek, wyrzuć obiekt specyficzny dla projektu Niefoundexception lub tym podobne. W tym przypadku kompilator mówi ci, jeśli zapomnisz obsłużyć wyjątek. (Jest to moja preferowana Obsługa nie znalezionych rzeczy w Javie.)
3. jeśli mówisz, że jest naprawdę ok, jeśli obiekt nie został znaleziony, a nazwa metody jest jak findbookforautororreturnnull(..), wtedy możesz zwrócić null. W tym przypadku jest to silnie zalecane do użycia pewnego rodzaju sprawdzania statycznego lub sprawdzania kompilatora, które zapobiega dereferencja wyniku bez sprawdzenia null. W przypadku Javy może to być np. FindBugs (zobacz DefaultAnnotation na http://findbugs.sourceforge.net/manual/annotations.html ) lub IntelliJ-Checking.

Bądź ostrożny, jeśli zdecydujesz się zwrócić null. Jeśli nie jesteś jedynym programistą w projekcie, otrzymasz NullPointerExceptions (w Javie lub gdziekolwiek w innych językach) w czasie wykonywania! Nie zwracaj więc wartości NULL, które nie są sprawdzane podczas kompilacji.

Jeśli używasz biblioteki lub innej klasy, która rzuca wyjątek, powinieneś rethrow it. Oto przykład. Przykład2.java jest jak biblioteka i przykład.java używa swojego obiektu. Main.przykładem obsługi tego wyjątku jest java. Powinieneś pokazać sensowną wiadomość i (w razie potrzeby) stos trace do użytkownika po stronie wywołującej.

Main.java

public class Main {
public static void main(String[] args) {
    Example example = new Example();

    try {
        Example2 obj = example.doExample();

        if(obj == null){
            System.out.println("Hey object is null!");
        }
    } catch (Exception e) {
        System.out.println("Congratulations, you caught the exception!");
        System.out.println("Here is stack trace:");
        e.printStackTrace();
    }
}
}

Przykład.java

/**
 * Example.java
 * @author Seval
 * @date 10/22/2014
 */
public class Example {
    /**
     * Returns Example2 object
     * If there is no Example2 object, throws exception
     * 
     * @return obj Example2
     * @throws Exception
     */
    public Example2 doExample() throws Exception {
        try {
            // Get the object
            Example2 obj = new Example2();

            return obj;

        } catch (Exception e) {
            // Log the exception and rethrow
            // Log.logException(e);
            throw e;
        }

    }
}

Przykład2.java

 /**
 * Example2.java
 * @author Seval
 *
 */
public class Example2 {
    /**
     * Constructor of Example2
     * @throws Exception
     */
    public Example2() throws Exception{
        throw new Exception("Please set the \"obj\"");
    }

}

To naprawdę zależy od tego, czy spodziewasz się znaleźć obiekt, czy nie. Jeśli postępujesz zgodnie ze szkołą myślenia, że wyjątki powinny być używane do wskazywania czegoś, cóż, błąd, wyjątek wystąpił wtedy:

• obiekt znaleziony; return obiekt
• Object not-found; throw exception

W Przeciwnym Razie zwracamy null.