L'utilisation bool (Type de retour) pour gérer les exceptions ou passer au client exception?

Question

Je suis en train de trouver la meilleure façon de traiter les exceptions, j'ai un certain nombre de couches à ma demande et a commencé à utiliser un type de retour de BOOL-à-dire si elle ne parvient alors retourner faux et si elle réussit retourne vrai ..

Cela fonctionne très bien dans les méthodes comme SaveMyRecord (somerecord); comme je passe des valeurs et ne nécessitent rien retourné pour que je puisse utiliser le type de retour de bool pour indiquer si elle réussit ou non.

Mais il m'a fait penser que des choses comme GetMyRecord () retourne en fait le type de IQueryable je ne peux donc pas utiliser un bool pour me dire si elle a échoué ou non.

La chose est que je suis gérer beaucoup de mes erreurs où ils se produisent avec try et catch et donc ne veulent pas le client de recevoir une exception.

Peut-être qu'il ya une meilleure façon, je puis fait penser à l'aide de paramètres OUT mais cela signifie que je dois changer la signature de toutes les méthodes et ajouter aditional params ..

Peut-être que je devrais passer le exception au client et la manipulation là?

Y at-il des normes ou des documents à adivse les meilleures pratiques?

Answer 1

Bubble up l'exception au client et le manipuler là. Sans aucun doute passer en détail complet sur toute la hauteur. La plupart des meilleures pratiques presque entièrement d'accord sur ce point, toujours enfin poignée sur le périmètre, dans ce cas, le CLIENT, mais dans d'autres cas qui pourrait être un service Web.

attrapez seulement si vous voulez log il, ajouter plus d'informations ou essayer de récupérer une exception particulière. Dans chaque cas, vous devrez soit lancer une nouvelle exception à l'original comme intérieur ou simplement « jeter » l'est comme original, et comme indiqué dans les commentaires ne pas « jeter ex »

Cette question est un près de double et que vous pouvez trouver beaucoup de questions très existantes bien répondu sur le SO. Je lui ai répondu un semblable seulement hier

Answer 2

Vous devriez commencer à lire Lignes directrices pour la conception des exceptions

Ensuite, en fonction de votre scénario, vous devez prendre d'autres considérations en compte, comme d'exception Shielding.

Par exemple: Si vous utilisez des services Web (ASMX ou WCF) en arrière-plan, vous pouvez jeter un oeil à Améliorer la sécurité des services Web et lire les parties concernant la gestion des exceptions.

Answer 3

Si une méthode ne peut pas faire son travail, il devrait lancer une exception. Ne jamais retourner une exception en conséquence.

Answer 4

L'approche qui est recommandée et considérée comme une meilleure pratique consiste à utiliser les exceptions. Vous pouvez (et devez) lire la cadre lignes directrices de conception (2e éd.) , qui a des lignes directrices pour les exceptions et le modèle try-parse.

Il y a quelques problèmes avec l'utilisation des codes de retour (numériques ou booléens), les deux plus grands être:

• facilement négligé / ignoré par les programmeurs.
• Ne peut pas être utilisé dans toutes les situations. Qu'advient-il si votre constructeur échoue? Il est impossible pour vous de retourner une valeur explicite d'un constructeur.

En ce qui concerne le moment de gérer les exceptions, vous ne devez les gérer quand vous pouvez faire quelque chose de significatif au sujet de l'exception. Le problème avec toujours la gestion des exceptions afin que le client ne les voit jamais est que vous pouvez finir par le traitement d'une exception que vous ne devriez pas avoir et causer plus de problèmes plus tard (comme les données réellement perdre).

Answer 5

une grande question!

Ne pas coder pour une exception. Pour la plupart, ils font semblant jamais eu lieu. Je me inquiète exception en deux endroits: Affichage des commentaires d'erreur à l'utilisateur et la gestion des ressources (à savoir la fermeture d'un fichier ouvert lorsqu'une exception est portée)

.

Answer 6

Un modèle commun MS semble aimer est d'avoir un procédé ComputeSomething () qui retourne « int », et un procédé TryComputingSomething () qui accepte une référence à un nombre entier et renvoie booléenne. Ce dernier, en cas de succès, stocke son calcul dans le passé en variable et retourne vrai; si elle échoue pour une raison « attendu », elle retourne Faux. Notez que les défaillances inattendues dans les deux routine peut lancer des exceptions.

Dans certains cas, il peut être utile d'utiliser un modèle différent, et une routine accepte un délégué à invoquer en cas de problème. Ce délégué peut soit renvoyer une exception, ou provoquer la routine sous-jacente pour revenir faux, ou peut-être faire d'autres choses. Notez que au moment où le délégué court, des informations seront disponibles qui seraient détruits avant toute exception pourrait être pris. Par exemple, si une routine est censé lire des lignes à partir d'un fichier et convertir les caractères 20-37 en date, il peut être utile de se connecter la ligne d'entrée entier s'il y a une erreur d'analyse. on pourrait le faire en utilisant un délégué passé dans,; sans une telle chose, ce serait beaucoup plus difficile.