Si les fonctions renvoient null ou un objet vide ?

Question

Quelle est la meilleure pratique lorsque le renvoi de données à partir de fonctions. Est-il mieux de retourner une valeur Null ou un objet vide? Et pourquoi devrait-on faire l'un sur l'autre?

Réfléchissez à ceci:

public UserEntity GetUserById(Guid userId)
{
     //Imagine some code here to access database.....

     //Check if data was returned and return a null if none found
     if (!DataExists)
        return null; 
        //Should I be doing this here instead? 
        //return new UserEntity();  
     else
        return existingUserEntity;
}

Disons qu'il y aurait des cas valides dans ce programme, qu'il n'y aurait pas des informations de l'utilisateur dans la base de données avec ce GUID. J'imagine qu'il ne serait pas opportun de lancer une exception dans ce cas?? Aussi, je suis sous l'impression que la gestion des exceptions peuvent nuire à la performance.

Answer 1

Retourner null est généralement la meilleure idée si vous avez l'intention d'indiquer qu'aucune donnée n'est disponible.

Un objet vide implique de données a été renvoyé, alors que de retourner la valeur null indique clairement que rien n'a été renvoyé.

En outre, en retournant une valeur null entraînera une exception nulle si vous tentez d'accéder aux membres de l'objet, qui peut être utile pour mettre en valeur buggy code de tenter d'accéder à un membre de rien n'a pas de sens. Accéder aux membres d'un objet vide ne manquera pas de sens de bugs peut aller découvrir.

Answer 2

Cela dépend de ce qui fait le plus de sens pour votre cas.

Est-il judicieux de retourner la valeur null, par exemple "utilisateur"?

Ou est-il préférable de créer un utilisateur par défaut? Ce qui fait le plus de sens lorsqu'il est raisonnable de supposer que si un utilisateur N'existe PAS, le code appelant entend de l'une d'exister quand ils la demandent.

Ou est-il judicieux de lever une exception (la "fichier introuvable") si le code d'appel est exigeant un utilisateur avec un ID non valide?

Toutefois - d'une séparation des préoccupations/SRP point de vue, les deux premiers sont plus correctes. Et techniquement, la première est la plus correcte (mais seulement d'un cheveu) - GetUserById ne devrait être responsable que pour une chose - obtenir de l'utilisateur. La gestion de ses propres "l'utilisateur n'existe pas" au cas par retour de quelque chose d'autre pourrait être une violation de la SRP. La séparation dans un autre check - bool DoesUserExist(id) serait le cas si vous choisissez de lancer une exception.

Basé sur des observations détaillées ci-dessous: si c'est une API au niveau de la conception, cette méthode pourrait être analogue à la "OpenFile" ou "ReadEntireFile". Nous sommes "l'ouverture" d'un utilisateur à partir de certains de référentiel et de l'hydratation de l'objet à partir de données obtenues. Une exception pourrait être appropriée dans ce cas. Il peut ne pas l'être, mais il pourrait être.

Toutes les approches sont acceptables - cela dépend, basée sur le contexte plus large de l'API/de l'application.

Answer 3

Personnellement, j’utilise la valeur NULL. Il est clair qu’il n’y a pas de données à renvoyer. Mais il y a des cas où un Objet Null peut être utile.

Answer 4

Si votre type de retour est un tableau puis retourner une valeur null sinon retour de tableau vide.

Answer 5

C'est une question de gestion, dépend de l'existence d'un utilisateur avec un Guid Id est une normale attendue cas d'utilisation de cette fonction, ou est-ce une anomalie qui empêche l'application de réussir quelle que soit la fonction de cette méthode est de fournir à l'utilisateur de l'objet...

Si c'est une "exception", en l'absence d'un utilisateur avec l'Id d'empêcher l'application de réussir quelle que soit la fonction qu'elle est en train de faire (Dire que nous sommes en train de créer une facture pour un client, nous avons livré d'un produit...), alors, cette situation doit lever une exception d'argument (ou une autre exception personnalisée).

Si un utilisateur manquant est ok, (l'un des potentiels normaux des résultats de l'appel de cette fonction), puis retourner null....

EDIT: (pour répondre au commentaire de Adam dans une autre réponse)

Si l'application contient plusieurs processus d'affaires, à un ou plusieurs de ce qui ont besoin d'un Utilisateur afin de mener à bien, et un ou plusieurs de ce qui peut compléter avec succès sans un utilisateur, l'exception doit être levée plus haut dans la pile d'appel, plus près de là où les processus d'affaires qui ont besoin d'un Utilisateur sont à l'appel de cette thread d'exécution. Méthodes entre cette méthode et que le point (où l'exception est levée) doit communiquer qu'aucun utilisateur n'existe (null, boolean, c'est un détail d'implémentation).

Mais si tous les processus au sein de l'application nécessitent un utilisateur, je serais encore à jeter l'exception à cette méthode...