Exceptions vs codes de résultat pour une classe de client de socket

Question

J'ai une classe qui encapsule les communications de socket TCP avec un serveur. Pour chaque message de commande envoyé au serveur, celui-ci renverra un message de réponse contenant invariablement un code de réponse (OK, Echec). En utilisant ma classe, chaque commande peut être exécutée de manière synchrone ou asynchrone.

Il existe fondamentalement deux types d'exceptions qui peuvent avoir lieu: un "défaut". Cela est dû à une déconnexion ou à une autre erreur non récupérable et à une exception inattendue du type "Le tampon d’envoi est plein". En cas d'erreur, aucune commande ne peut continuer ou essayer à nouveau ou quoi que ce soit jusqu'à ce que la connexion soit rétablie. En cas d’échec ou même d’exception, la commande peut être réessayée ...

Donc, pour le moment, mes méthodes de commande de synchronisation renvoient une énumération qui peut avoir les valeurs suivantes: OK, Echec, Défaut. Si une exception se produit, elle est simplement élevée vers le thread appelant (dans une commande de synchronisation). Pour les commandes asynchrones, la valeur enum de la propriété Result peut contenir une valeur supplémentaire: OK, Fail, Fault ou Exception et le rappel peut accéder à l'objet exception réel via la propriété Exception de l'objet de commande.

Que pensez-vous de cette stratégie? Je suis tenté de ne pas déclencher d'exceptions du tout pour les commandes de synchronisation, mais simplement de consigner l'exception en interne et de renvoyer la valeur 4 enum à la place, car c'est tout ce que je ferai avec les exceptions dans tous les cas de toute façon ... Ou, si je n'utilisais pas codes de résultat du tout et soulèvent des exceptions dans tous les cas, même les fautes?

Merci.

Answer 1

Je pense que votre stratégie est fondamentalement saine.

N'oubliez pas que le but de Exceptions est de traiter des conditions exceptionnelles. Le plus proche de la source du problème, mieux ce sera.

Dans votre cas, il semble que votre stratégie ressemble à "Cela n’a pas fonctionné pour le moment. Réessayons " ;. Je ne vois pas de raison de vraiment soulever des exceptions.

Si traiter avec une socket fermée demandait un flux totalement différent dans votre code, des exceptions auraient peut-être du sens. D'après votre description, ce n'est pas vraiment le cas.

Ma philosophie sur les exceptions est qu’elles devraient être destinées à des conditions exceptionnelles auxquelles vous ne pouvez pas vraiment faire face. Une prise fermée? Hmm ... combien de fois Internet tombe-t-il chez moi ...

Answer 2

Je préférerais que vous leviez une exception chaque fois que votre méthode ne termine pas sa mission avec succès. Donc, si je, l'appelant, appelle yourObject.UploadFile (), je supposerai que le fichier a été téléchargé avec succès au retour de l'appel. Si cela échoue pour une raison quelconque, je suppose que votre objet lève une exception. Si vous voulez faire la distinction entre les commandes que je peux réessayer et les commandes que je ne devrais pas réessayer, mettez ces informations dans l'exception et je peux décider comment réagir en conséquence.

Lorsque vous appelez yourObject.BeginAsyncUploadFile (), je m'attendrais au même comportement, sauf que je devrais attendre l'objet IAsyncResult ou équivalent pour savoir si le téléchargement du fichier a réussi ou non, puis vérifier une exception / erreur. propriété si elle ne le faisait pas.

Answer 3

Les codes de résultat et les exceptions peuvent fonctionner correctement. C'est une question de goût personnel (et du goût des autres membres de votre équipe). Les exceptions présentent certains avantages, en particulier dans les contextes plus complexes, mais dans votre contexte, cela semble assez simple pour que les codes de retour fonctionnent correctement.

Certaines personnes vont mousser à la bouche et insister sur les exceptions, mais dans mon projet, les gens aiment la simplicité des codes de retour, ce qui en fait le meilleur choix dans l'ensemble.

Answer 4

C'est une question plutôt intéressante. En tant que tel, il n’ya probablement pas de réponse '100% correcte', et cela dépend principalement de la structure du code utilisant votre fonction.

Selon moi, vous utilisez des exceptions uniquement lorsque vous souhaitez fournir au code appelant votre fonction un moyen d'échapper gracieusement à une situation "désastreuse". Donc, dans mon code, je lance normalement une exception lorsque quelque chose de vraiment, vraiment horrible se produit, et que l'appelant doit savoir.

Maintenant, si ce que vous avez est une situation normale et attendue, vous devriez probablement renvoyer une valeur d'erreur. De cette façon, le code sait qu’il doit «essayer plus fort», mais il ne sera pas compromis par ce qui s’est passé.

Dans votre cas, par exemple, vous pouvez traiter les délais d'attente comme prévu et ainsi renvoyer un code d'erreur et des problèmes plus graves (comme un tampon d'envoi complet) dans lesquels le code appelant doit effectuer des actions supplémentaires pour revenir en arrière. à 'normal' à titre d'exception.

Mais alors, la beauté est dans l'œil du spectateur, et certaines personnes vous diront de n'utiliser que des exceptions, d'autres (principalement des programmeurs C) de n'utiliser que des codes de retour. Rappelez-vous simplement que les exceptions doivent toujours être exceptionnelles. :)