2010-05-14 50 views
1

我在写一个即时消息库。目前,在读取或写入套接字时引发SocketException时,我将从应用程序内部启动注销例程,并将SocketException作为LogoutEventArgs的参数传递给最终用户。这为最终用户提供了一种查看实际导致未请求注销的潜在异常的方法。如何在注销例程期间处理套接字错误

我的问题是,我要做什么,如果在用户调用Logout函数期间,套接字实际上会引发异常。

示例 - 最终用户调用Logout函数,并且在注销函数正在等待现有请求正常结束时,套接字在读线程中引发异常。

我有两个选择,因为我看到它 -

  1. 假装没有发生错误,而只是像断开作为我们注销的部件用插座。

  2. 当发生套接字异常时,请查看是否发生注销请求,如果是,则覆盖它。导致原始注销请求抛出AlreadyLoggedOutException,以及在LogoutEventArgs中传递异常的单独注销事件。

而且,稍相关 - 我是什么来如果服务器启动,这不是请求关闭(即.. read调用返回null)..在.NET Messenger的服务器有这种倾向做这如果你发送一个它不喜欢的请求。我是否将其视为例外?

我发现我的图书馆的整个断开/注销部分是我身边的一个主要刺。我似乎无法绕过它。有没有人知道任何处理这种情况的开源代码应用程序?

我一直试图在脑海中解决这个问题很长时间,这让我很生气。

回答

0

我决定不将SocketException传递给最终用户,因为断开并不是一个真正的例外,应该被期待和处理。相反,LogoutEventArgs上有一个LogoutReason属性,它指定注销发生的原因。

我决定,如果在注销期间发生断开连接,那实际上并不是例外情况,因为注销将会断开连接。在这种情况下,我只是无视例外。