我正在写一个即时消息库。目前，当在读取或写入套接字时引发SocketException时，我从应用程序内部启动注销例程，将SocketException作为LogoutEventArgs的参数传递给enduser。这为最终用户提供了一种方法，可以查看实际导致未请求注销的基础异常。
我的问题是，我该怎么做，如果在用户调用Logout函数期间，套接字实际上会抛出异常。
示例 - 最终用户调用Logout函数，当logout函数正在等待现有请求正常结束时，套接字会在读取线程中引发异常。
我看到它有两个选项 -
假装没有发生错误，只是像我们的退出一样断开套接字。
引发套接字异常时，查看是否发生了注销请求，如果是，请覆盖它。导致抛出AlreadyLoggedOutException的原始Logout请求，以及在LogoutEventArgs中传递异常的单独logout事件。
另外，稍微相关 - 如果服务器启动未请求的关闭（即，读取调用返回null），我该怎么办..如果发送，.NET Messenger服务器倾向于执行此操作一个它不喜欢的请求。我是否将此视为例外？
我发现我的图书馆的整个断开/退出部分是我身边的主要荆棘。我似乎无法绕过它。有没有人知道任何能够很好地处理这种情况的开源代码应用程序？
我一直在努力解决这个问题，这让我很生气。
答案 0 :(得分：0)
我决定不将SocketException传递给最终用户，因为断开连接不是真正的异常，应该是预期和处理的。而是在LogoutEventArgs上有一个LogoutReason属性，它指定了注销发生的原因。
我决定，如果在Logout期间发生断开连接，那么这实际上并不是例外，因为注销无论如何都会断开连接。在这种情况下，我只是忽略了例外。