Exceptions - Les meilleures pratiques

Question

J'ai pensé en général au sujet de la gestion des exceptions.

Quelle serait la meilleure pratique pour la mise en œuvre d'une méthode qui obtient un objet User en fonction du paramètre de nom d'utilisateur fourni. Voir ci-dessous.

/// <summary> 
    /// Gets a user. 
    /// </summary> 
    /// <param name="username">Username</param> 
    /// <returns>User instance</returns> 
    public Model.User GetUser(string username) 
    { 
     return Context.Users.SingleOrDefault(u => u.Username.ToLower() == username.ToLower()); 
    } 

si aucun utilisateur existe avec ce paramètre username, serait-il préférable de retourner un objet nul User ou plutôt lancer une exception personnalisée précisant que l'utilisateur n'existe pas.

Answer 1

Throw une exception . Dans le cas contraire, votre interlocuteur et d'autre de l'appelant de votre correspondant, et tout le monde devra vérifier null, ou devront gérer une collection vide.

S'il s'agit d'une méthode à usage général, destinée à être utilisée dans un contexte où l'appelant sait il doit vérifier null, alors je le ferais un peu différemment. J'aurais une méthode private qui renvoie null si aucun utilisateur ne correspond. Je voudrais ajouter un appelant qui utilise le modèle « essayer »:

public bool TryGetUser(string username, out Model.User user) 

et aussi celui qui retourne simplement à l'utilisateur, mais lève une exception si elle est introuvable

public Model.User GetUser(string username) 

Answer 2

Mon conseil serait si le programme ne peut pas continuer sans utilisateur, puis lancer une exception. Si c'est ok que vous ne pouvez pas trouver un utilisateur ou que ce serait une erreur de connexion alors je retournerais null. Je ne lancerais une exception que si le programme ne pouvait pas continuer sans obtenir l'utilisateur et qu'il ne pouvait pas dire redirect pour se reconnecter.

Rappelez-vous lancer une exception est plus d'une opération coûteuse que le retour nul trop (je veux dire rien remarquer et ne pense comme ça (micro-optimisation) mais des exceptions devrait être utilisé pour la logique métier normal)

Answer 3

Je dirais que la méthode d'appel peut décider si le résultat de l'absence d'un utilisateur nécessite ou non le lancement d'une exception. Si un nom d'utilisateur est fourni, mais pas trouvé, retourner null a un sens pour moi et laisser le code appelant décider comment il doit procéder.

Étant donné la façon dont la méthode est générique, pourquoi voudriez-vous jeter une exception si un nom d'utilisateur fourni ne se trouve pas? C'est une chose si une erreur de base de données se produit, etc, mais si le SELECT ne donne pas de lignes, je pense que ce n'est pas exceptionnel.

Answer 4

D'abord, je veux simplement suggérer une amélioration de votre mode de comparaison de chaînes sans sensibilité à la casse.

/// <summary> 
/// Gets a user. 
/// </summary> 
/// <param name="username">Username</param> 
/// <returns>User instance</returns> 
public Model.User GetUser(string username) 
{ 
    return Context.Users.SingleOrDefault(u => 
     string.Compare(u.Username, username, true)); 
} 

String.Compare on MSDN

Maintenant, ma suggestion sur cette question

Plutôt que nulle de retour. Vous souhaiterez peut-être retourner un objet nul, en utilisant le null object pattern.

public class User 
{ 

    public static readonly User Null = new Null{Username = "Anonymous"}; 

    ... 

} 

Ensuite, votre méthode devient:

public Model.User GetUser(string username) 
{ 
    return Context.Users.SingleOrDefault(u => 
     string.Compare(u.Username, username, true)) ?? Model.User.Null; 
} 

Ceci est utile dans les situations où null est indésirable. Il supprime le besoin de vérifier null plus tard. Si cet objet utilisateur a des droits associés par exemple, vous pouvez simplement vous assurer que l'utilisateur "null" n'a aucun droit.

Answer 5

Je ne suis pas d'accord avec les réponses précédemment affichées.

Les exceptions ne doivent être utilisées que dans circonstances exceptionnelles. Ne pas trouver une valeur correspondante n'est pas exceptionnel. IMO, retourner null est beaucoup plus élégant - il laisse la décision de lancer une exception à l'appelant, pas l'appelé, et cela a du sens; vous demandez la méthode pour un utilisateur et s'il n'y en a pas, il ne retourne rien. De plus, votre code et l'autre répondent à travers l'ensemble de la collection à chaque fois, ce qui sera inutilement lent. Vous devriez utiliser un dictionnaire pour les recherches rapides (à moins, bien sûr, de fréquentes modifications de la collection Users qui rendent la mise en cache impossible).

Exemple:

class MyClass 
{ 
    private Dictionary<String,User> _userLookup; 

    public MyClass() 
    { 
     _userLookup = Context.Users.ToDictionary(u => u.UserName.ToLower()); 
    } 

    private User getUserByName(String name) 
    { 
     var lowerName = name.ToLower(); 
     return _userLookup.ContainsKey(lowerName) ? _userLookup[lowerName] : null; 
    }  
}