J'écris une bibliothèque de messagerie instantanée. Actuellement, lorsqu'une exception SocketException est déclenchée lors de la lecture ou de l'écriture sur le socket, je lance la routine de déconnexion à partir de l'application, en passant l'exception SocketException à l'utilisateur final en tant qu'argument de LogoutEventArgs. Cela permet à l'utilisateur final de voir quelle exception sous-jacente a réellement causé la déconnexion non demandée.Comment gérer une erreur de socket lors d'une routine de déconnexion
Ma question, est ce que je dois faire, si lors d'un appel de l'utilisateur à la fonction de déconnexion, le socket jette effectivement une exception. Exemple - Fonction de déconnexion des appels d'utilisateurs finaux, et pendant que la fonction de déconnexion attend que les requêtes existantes se terminent correctement, le socket envoie une exception dans le thread de lecture.
J'ai deux options que je vois -
Pretend l'erreur ne se produit pas, et juste agir comme la prise débranchée dans le cadre de notre déconnexion.
Lorsque l'exception de socket est déclenchée, vérifiez si une demande de déconnexion est en cours et, si c'est le cas, remplacez-la. Résultat: la requête Logout d'origine lançant une exception AlreadyLoggedOutException, ainsi qu'un événement de déconnexion distinct qui transmet l'exception dans LogoutEventArgs.
En outre, un peu racontais - Que dois-je faire si le serveur lance un arrêt qui n'a pas été demandé (c.-à .. l'appel retourne de lecture null) .. le serveur .NET Messenger a tendance à faire ceci si vous envoyez une demande il n'aime pas. Est-ce que je traite cela comme une exception en soi?
J'ai trouvé l'ensemble de la déconnexion/déconnexion de ma bibliothèque comme une épine dans mon pied. Je n'arrive juste pas à envelopper ma tête. Est-ce que quelqu'un connaît des applications de code source ouvert qui gèrent magnifiquement cette situation?
J'ai essayé d'aborder cette chose dans ma tête depuis si longtemps, ça me rend fou.