Usługa powinna zgłosić wyjątek lub zwrócić, gdy nie określono żadnych elementów do usunięcia

Mam fragment kodu, który można przedstawić jako:

public class ItemService {

    public void DeleteItems(IEnumerable<Item> items)
    {
        // Save us from possible NullReferenceException below.
        if(items == null)
            return;

        foreach(var item in items)
        {
            // For the purpose of this example, lets say I have to iterate over them.
            // Go to database and delete them.
        }
    }
}

Teraz zastanawiam się, czy jest to właściwe podejście, czy powinienem rzucić wyjątek. Mogę uniknąć wyjątku, ponieważ zwracanie byłoby tym samym, co iteracja po pustej kolekcji, co oznacza, że ​​i tak żaden ważny kod nie jest wykonywany, ale z drugiej strony prawdopodobnie ukryję gdzieś problemy w kodzie, ponieważ dlaczego ktoś miałby dzwonić DeleteItemsz nullparametrem? Może to oznaczać, że w kodzie występuje problem.

Jest to problem, który zwykle mam z metodami w usługach, ponieważ większość z nich coś robi i nie zwraca wyniku, więc jeśli ktoś przekaże nieprawidłowe informacje, usługa nie ma nic do zrobienia, więc zwraca.

To są dwa różne pytania.

Czy powinieneś zaakceptować null? To zależy od twojej ogólnej zasady nullw bazie kodu. Moim zdaniem banowanie nullwszędzie, z wyjątkiem przypadków, w których jest to wyraźnie udokumentowane, jest bardzo dobrą praktyką, ale jeszcze lepszą praktyką jest przestrzeganie konwencji, którą posiada już twoja baza kodu.

Czy powinieneś zaakceptować pustą kolekcję? Moim zdaniem: TAK, absolutnie. Znacznie większy wysiłek stanowi ograniczenie wszystkich osób dzwoniących do niepustych kolekcji niż zrobienie matematycznie właściwej rzeczy - nawet jeśli zaskakuje to niektórych programistów, którzy nie mają pojęcia o zero.

Wartość zerowa

Jak już powiedział @KilianFoth, trzymaj się swojej ogólnej polityki. Jeśli ma to być traktowane nulljako „skrót” dla pustej listy, zrób to w ten sposób.

Jeśli nie masz spójnych zasad dotyczących nullwartości, polecam następującą:

nullpowinny być zarezerwowane do reprezentowania sytuacji, których nie można wyrazić typem „normalnym”, np. używanie nulldo reprezentowania „Nie wiem”. I to dobry wybór, ponieważ każdy, kto spróbuje niedbale wykorzystać tę wartość, otrzyma wyjątek, co jest słuszne.

Użycie nullskrótu do pustej listy nie kwalifikuje się w ten sposób, ponieważ istnieje już idealna reprezentacja, będąc listą z zerowymi elementami. Jest to technicznie zły wybór, ponieważ zmusza każdą część kodu zajmującą się listami do sprawdzenia poprawności skrótu null.

Pusta lista

W przypadku DeleteItems()metody przekazanie pustej listy skutecznie oznacza nic nie robienie. Pozwoliłbym na to jako argument, nie rzucając wyjątku, po prostu wracając szybko.

Oczywiście, osoba dzwoniąca może najpierw sprawdzić zero elementów i DeleteItems()w takim przypadku pominąć połączenie. Jeśli mówimy o internetowym interfejsie API, ze względów wydajności osoba dzwoniąca powinna to zrobić, aby uniknąć niepotrzebnego ruchu i opóźnień w obie strony. Ale nie sądzę, że Twój interfejs API powinien to wymuszać.

Zgłaszaj wyjątek i obsługuj wartości zerowe w kodzie wywołującym.

Z reguły należy unikać wartości null jako wartości parametrów. Zmniejszy to ogólnie NullPointerExceptions, ponieważ wartości null będą naprawdę wyjątkiem.

Poza tym spójrz na resztę swojego kodu. Jeśli jest to powszechny wzór w twoim projekcie, zachowaj spójność.

Ogólnie rzecz biorąc, zgłaszanie wyjątków powinno być zarezerwowane na wyjątkowe sytuacje, tj. Jeśli kod nie ma rozsądnego sposobu działania w obecnym kontekście.

Możesz zastosować ten proces myślowy do tej sytuacji. Biorąc pod uwagę, że jest to klasa publiczna z publiczną metodą, masz publiczny interfejs API i teoretycznie nie masz kontroli nad tym, co zostanie mu przekazane.

Twój kod nie ma kontekstu na temat tego, co go nazywa (jak nie powinien), i nic nie możesz zrobić z wartością zerową. Z pewnością byłby to kandydat na ArgumentNullException.

To pytanie wydaje się nie dotyczyć wyjątków, ale nullbyć ważnym argumentem.

Przede wszystkim musisz zdecydować, czy nullargument jest dozwolony dla argumentu tej metody. Jeśli tak, to nie potrzebujesz wyjątku. Jeśli tak nie jest, potrzebujesz wyjątku.

To, czy chcesz na to zezwolić null, czy nie, jest dyskusyjne, o czym świadczy wiele hitów Google na ten temat. Oznacza to, że nie dostaniesz jasnej odpowiedzi i zależy to w pewnym stopniu od opinii i tradycji w miejscu pracy.

Inną kwestią sporną jest to, czy funkcja biblioteczna powinna być naprawdę surowa w stosunku do takich rzeczy, czy tak łagodna, jak to możliwe, o ile nie próbuje ona „naprawić” błędnych parametrów. Porównaj to ze światem protokołów sieciowych, przesyłania poczty itp. (Które są umowami interfejsowymi, podobnie jak metody programowania). Tam zwykle obowiązuje zasada, że ​​nadawca powinien możliwie ściśle przestrzegać protokołu, a odbiorca powinien starać się pracować z tym, co nadchodzi.

Musisz więc zdecydować: czy naprawdę zadaniem metody bibliotecznej jest egzekwowanie dość dużych zasad, takich jak nullobsługa? Zwłaszcza jeśli Twoja biblioteka jest używana również przez inne osoby (które mogą mieć inne zasady).

Prawdopodobnie popełniłbym błąd po stronie dopuszczania nullwartości, definiowania i dokumentowania ich semantyki (tj. null = empty arrayW tym przypadku), i nie rzucałbym wyjątku, chyba że 99% twojego innego podobnego kodu (kodu w stylu „biblioteki”) robi to w drugą stronę 'okrągły.