Quand utiliser une exception ou quand utiliser un message?

Cela dépend, surtout, vous gérez les conditions communes susceptibles de se produire (telles que la connexion de base de données dans votre exemple) en utilisant une déclaration si code>. D'autres situations pouvant survenir et vous pensez que votre code ne les couvrira pas toutes, utilisez Exceptions code>, de cette façon, vous vous assurez que vous attrapez la trace d'erreur.

Certains autres cas peuvent avoir besoin de si code> et exception code>. p>

Exemple: p>

try
{
    if(!string.IsNullOrEmpty(someString))
    {
        someClass.Run(someString);
    }
}
catch(Exception ex)
{
    // Log exception 
}

Donc, quel code est plus correct, d'utiliser des exceptions ou des messages à avertir L'utilisateur Les informations ne sont pas correctes? Y a-t-il un autre meilleur options?

n'est pas non plus plus correct et ils affichent tous les deux le message à l'utilisateur avec ou sans exception; mission accomplie. En effet, vous n'empêcheriez pas l'utilisateur avec une exception par exemple, il est donc transparent pour eux, sauf si vous envisagez de jeter la trace de la pile à l'interface utilisateur (non !!). Il y a des choses à considérer lorsque vous utilisez des exceptions et que vous ne voulez certainement pas les utiliser partout pour tout, mais ce n'est pas mauvais pour les utiliser pour des défaillances de validation. Lisez-y pour plus.

---

Exceptions sont signifiées pour des conditions exceptionnelles, mais ce qui constitue une condition exceptionnelle varie. Premier < / code> , par exemple, jetera une exception si la source ou prédicat est null, la source est vide, ou Il n'y a pas d'élément qui correspond au prédicat . Ils auraient pu juste retourner NULL, mais ils ont choisi de pousser la responsabilité sur l'appelant pour le faire correctement. Pour moi, c'est une utilisation raisonnable d'exceptions où ce n'était pas exactement nécessaire; Une collection ne contenant pas d'élément qui correspond à un prédicat arrive tout le temps, donc ce n'est pas exactement exceptionnel. Et il n'est pas rare de voir argumentexception s et argumentnullexception s utilisé dans des cas similaires comme le vôtre; C'est probablement comment je ferais probablement une approche plus sophistiquée.

Mais, première chose d'abord. Je sais que c'est un exemple, mais certains points de douleur doivent être abordés avant de se préoccuper de l'approche plus appropriée.

Ce qui suit est objectivement stky : xxx

ici, le code utilise des exceptions comme le flux de contrôle . Vous savez que quelque chose ne va pas et peut le gérer à ce stade mais jeter à la place et attraper une exception pour montrer le message; pas bon.

aussi, ne pas jeter ni attraper system.exception . Des exceptions, si elles sont utilisées, doivent être suffisamment spécifiques pour faire quelque chose de significatif à ce sujet en fonction du contexte. Encore une fois, c'est un petit exemple, mais ce genre de chose est partout dans le code naïf.

ayant dit que, le premier exemple changerait et n'attraperait pas le argumentException si jeté. Laissez l'appelant attraper les erreurs comme elles sont celles qui créent la condition exceptionnelle; En d'autres termes, tirez la validation. L'appelant devrait également s'inquiéter de ce qu'il faut faire à ce sujet. Comme il est maintenant, le code de validation est étroitement couplé à une boîte de message qui rend difficile la réutilisation. xxx

donné, nous sommes prêts à supprimer le couplage dans la boîte de message, le deuxième exemple ne fait pas vraiment ce que nous voulons, donc créer un validationResult classe qui peut vous aider à créer un message significatif à l'utilisateur.