如何处理注销例程期间的套接字错误
我正在编写一个即时消息库。目前，当读取或写入套接字时引发 SocketException 时，我从应用程序内部启动注销例程，将 SocketException 作为 LogoutEventArgs 的参数传递给最终用户。这为最终用户提供了一种查看到底是什么底层异常导致未经请求的注销的方法。
我的问题是，如果在用户调用 Logout 函数期间，套接字实际上抛出异常，我该怎么办。
示例 - 最终用户调用注销函数，当注销函数等待现有请求正常结束时，套接字在读取线程中引发异常。
我看到有两个选择 -
假装错误没有发生，就像作为注销的一部分断开的套接字一样。
当引发套接字异常时，查看是否正在发生注销请求，如果是，则覆盖它。导致原始注销请求抛出 AlreadyLoggedOutException，以及一个单独的注销事件，该事件在 LogoutEventArgs 中传递异常。
另外，稍微相关 - 如果服务器启动未请求的关闭（即读取调用返回 null），我该怎么办。如果您发送请求，.NET Messenger 服务器倾向于执行此操作不喜欢。我是否将其视为例外？
我发现整个断开/注销我的图书馆的一部分是我的一大刺。我似乎无法理解它。有谁知道有任何开源代码应用程序可以完美地处理这种情况吗？
长期以来，我一直试图在脑海中解决这个问题，这让我发疯。
I am writing an instant messaging library. Currently, when a SocketException is raised while reading or writing to the socket, I start the logout routine from inside the application, passing the SocketException to the enduser as an argument of the LogoutEventArgs. This gives the end user a way of seeing what underlying exception actually caused the unrequested logout.
My question, is what am I to do, if during a user call to the Logout function, the socket actually throws an Exception.
Example - End user calls Logout function, and while the logout function is waiting for existing requests to end gracefully, the socket throws an exception in the reading thread.
I have two options as I see it -
Pretend the error didn't occur, and just act like the socket disconnected as part of our Logout.
When the socket exception is raised, see if a logout request is taking place, and if so, override it. Resulting in the original Logout request throwing an AlreadyLoggedOutException, as well as a separate logout event which passes the exception in the LogoutEventArgs.
Also, slightly related - What am I to do if the server initiates a shutdown that wasn't requested (ie.. the read call returns null).. the .NET Messenger server has a tendency to do this if you send a request it doesn't like. Do I treat this as an exception in itself?
I have found the whole disconnecting/logging out part of my library to be a major thorn in my side. I just can't seem to wrap my head around it. Does anyone know of any open source code applications that handle this situation beautifully?
I have been trying to tackle this thing in my head for so long, it's driving me mad.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我决定不将 SocketException 传递给最终用户，因为断开连接并不是真正的异常，应该进行预期和处理。相反，LogoutEventArgs 上有一个 LogoutReason 属性，用于指定发生注销的原因。
我决定，如果在注销期间发生断开连接，那么这实际上并不是一个例外，因为注销无论如何都会断开连接。我只是忽略了这种情况下的例外情况。
I decided not to pass the SocketException to the end user, as a disconnect is not truly an exception and should be expected and dealt with. Instead there is a LogoutReason property on the LogoutEventArgs which specifies why the logout occured.
I decided that if the disconnect occurs during Logout then that's not actually an exception for, as the logout was going to disconnect anyway. I simply disregard the exception in this case.