Comment gérer l'erreur de socket pendant la routine de déconnexion

Question

J'écris une bibliothèque de messagerie instantanée. Actuellement, lorsqu'une SocketException est augmentée lors de la lecture ou de l'écriture dans le socket, je commence la routine de déconnexion à l'intérieur de l'application, passant le socketException à l'EndUser comme argument des LogOUTEventArgs. Cela donne à l'utilisateur final un moyen de voir quelle exception sous-jacente a réellement provoqué la déconnexion non demandée.

Ma question, c'est ce que je dois faire, si pendant un appel utilisateur à la fonction de déconnexion, le socket lance en fait une exception.

Exemple - Fonction des appels de l'utilisateur final, et bien que la fonction de déconnexion attend que les demandes existantes se terminent gracieusement, le socket lance une exception dans le thread de lecture.

J'ai deux options comme je le vois -

1. Imaginez que l'erreur ne s'est pas produite et agissez simplement comme la prise déconnectée dans le cadre de notre déconnexion.

2. Lorsque l'exception du socket est soulevée, voyez si une demande de déconnexion a lieu et, dans l'affirmative, remplacez-la. Entraînant la demande de déconnexion originale qui lance une déjàtinée déjà LoggedoutException, ainsi qu'un événement de déconnexion séparé qui passe l'exception dans les LogOUTEventArgs.

Aussi, légèrement lié - que dois-je faire si le serveur initie un arrêt qui n'a pas été demandé (c'est-à-dire que l'appel de lecture renvoie null) .. le serveur .NET Messenger a tendance à le faire si vous envoyez une demande Je n'aime pas. Dois-je traiter cela comme une exception en soi?

J'ai trouvé que l'ensemble de la déconnexion / de la déconnexion d'une partie de ma bibliothèque était une épine majeure à mes côtés. Je n'arrive pas à enrouler ma tête autour. Quelqu'un connaît-il des applications de code open source qui gèrent magnifiquement cette situation?

J'essaie de m'attaquer à cette chose dans ma tête depuis si longtemps, ça me rend fou.

Answer 1

J'ai décidé de ne pas transmettre le socketexception à l'utilisateur final, car une déconnexion n'est pas vraiment une exception et devrait être attendue et traitée. Au lieu de cela, il existe une propriété LogouTRaison sur les LogouteventArgs qui spécifie pourquoi la déconnexion s'est produite.

J'ai décidé que si la déconnexion se produit pendant la déconnexion, ce n'est pas une exception pour, car la déconnexion allait se déconnecter de toute façon. Je ne tiens pas compte de l'exception dans ce cas.