Le service doit-il lever une exception ou revenir si aucun élément n'est spécifié pour la suppression

J'ai un morceau de code qui peut être représenté comme:

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.
        }
    }
}

Maintenant, je me demande si c'est la bonne approche ou dois-je lever l'exception. Je peux éviter les exceptions, car retourner serait la même chose que d'itérer sur une collection vide, ce qui signifie qu'aucun code important n'est exécuté de toute façon, mais d'un autre côté, je cache peut-être des problèmes quelque part dans le code, car pourquoi quelqu'un voudrait-il appeler DeleteItemsavec nullparamètre? Cela peut indiquer qu'il y a un problème ailleurs dans le code.

C'est un problème que j'ai généralement avec les méthodes dans les services, car la plupart d'entre elles font quelque chose et ne renvoient pas de résultat, donc si quelqu'un transmet des informations invalides, il n'y a rien à faire pour le service, donc il revient.

Ce sont deux questions différentes.

Devriez-vous accepter null? Cela dépend de votre politique générale nulldans la base de code. À mon avis, interdire nullpartout sauf là où cela est explicitement documenté est une très bonne pratique, mais c'est encore mieux de s'en tenir à la convention que votre base de code a déjà.

Devriez-vous accepter la collection vide? À mon avis: OUI, absolument. Il faut beaucoup plus d'efforts pour restreindre tous les appelants à des collections non vides que pour faire ce qui est mathématiquement juste - même si cela surprend certains développeurs qui ne savent pas exactement le concept de zéro.

Valeur nulle

Comme l'a déjà dit @KilianFoth, respectez votre politique générale. Si cela doit être considéré nullcomme un "raccourci" pour une liste vide, faites-le de cette façon.

Si vous n'avez pas de politique cohérente sur les nullvaleurs, je recommanderais la suivante:

nulldevrait être réservé pour représenter des situations qui ne peuvent pas être exprimées par le type "normal", par exemple en utilisant nullpour représenter "je ne sais pas". Et c'est un bon choix, car tous ceux qui essaient d'utiliser cette valeur sans précaution recevront une exception, ce qui est la bonne chose.

L'utilisation nullcomme raccourci pour une liste vide ne se qualifie pas de cette façon, car il existe déjà une représentation parfaite, étant une liste avec zéro élément. Et c'est un mauvais choix technique, car il oblige chaque partie de votre code traitant des listes à vérifier la sténographie valide null.

Liste vide

Pour une DeleteItems()méthode, passer une liste vide signifie effectivement ne rien faire. J'autoriserais cela comme argument, sans lever d'exception, mais simplement revenir rapidement.

Bien sûr, l'appelant pourrait d'abord vérifier l'absence d'éléments et ignorer l' DeleteItems()appel dans ce cas. Si nous parlons d'une API Web, pour des raisons d'efficacité, l'appelant devrait en fait le faire pour éviter le trafic inutile et les latences aller-retour. Mais je ne pense pas que votre API devrait appliquer cela.

Lancez une exception et gérez les valeurs NULL dans le code appelant.

En règle générale, essayez d'éviter null en tant que valeurs de paramètre. Cela réduira les NullPointerExceptions en général, car les valeurs nulles seront vraiment une exception.

En plus de cela, regardez le reste de votre code. S'il s'agit d'un modèle courant dans votre projet, restez cohérent.

De manière générale, la levée d'exceptions devrait être réservée à des situations exceptionnelles, c'est-à-dire si le code n'a pas de ligne de conduite raisonnable à prendre dans le contexte actuel.

Vous pouvez appliquer ce processus de réflexion à cette situation. Étant donné qu'il s'agit d'une classe publique avec une méthode publique, vous avez une API publique et en théorie aucun contrôle sur ce qui lui est transmis.

Votre code n'a aucun contexte sur ce qui l'appelle (comme il ne devrait pas), et il n'y a rien que vous puissiez raisonnablement faire avec une valeur nulle. Ce serait certainement un candidat pour un ArgumentNullException.

Cette question ne semble pas concerner les exceptions, mais nullêtre un argument valable.

Donc, vous devez d'abord et avant tout décider s'il nulls'agit d'une valeur autorisée pour votre argument de cette méthode. Si c'est le cas, vous n'avez pas besoin d'une exception. Si ce n'est pas le cas, vous avez besoin d'une exception.

Que vous souhaitiez autoriser nullou non est discutable, comme en témoignent de nombreux hits Google à ce sujet. Cela signifie que vous n'obtiendrez pas de réponse claire et que cela dépend quelque peu de l'opinion et de la tradition de l'endroit où vous travaillez.

Un autre point litigieux est de savoir si une fonction de bibliothèque doit être vraiment stricte à ce sujet, ou aussi indulgente que possible, tant qu'elle n'essaie pas de «corriger» des paramètres erronés. Comparez cela au monde des protocoles réseau, du transfert de courrier, etc. (qui sont des contrats d'interface, tout comme les méthodes de programmation). Là, généralement, la politique est que l'expéditeur doit se conformer le plus strictement possible au protocole, tandis que le récepteur doit se mettre en quatre pour pouvoir travailler avec tout ce qui se présente.

Vous devez donc décider: est-ce vraiment le travail d'une méthode de bibliothèque d'appliquer une politique assez large comme la nullgestion? Surtout si votre bibliothèque est également utilisée par d'autres personnes (qui peuvent avoir des politiques différentes).

Je préférerais probablement autoriser les nullvaleurs, définir et documenter leur sémantique (c'est- null = empty arrayà- dire dans ce cas), et ne pas lever d'exception, à moins que 99% de votre autre code similaire (code de style "bibliothèque") ne le fasse dans l'autre sens. 'rond.