我有一个类封装了与服务器的tcp套接字通信。对于发送到服务器的每条命令消息,服务器将发回一条响应消息,该响应消息总是包含响应代码(OK,Fail)。使用我的类,每个命令都可以执行同步或异步。

基本上可以发生两种类型的异常:“故障”。这是由断开连接或其他一些不可恢复的错误以及“发送缓冲区已满”之类的意外异常引起的。如果发生故障,在重新建立连接之前,任何命令都不能继续或再次尝试。如果发生故障响应甚至异常,可以再次尝试该命令......

所以,现在我的sync命令方法返回一个可以包含以下值的枚举:OK,Fail,Fault。如果发生异常,则将其简单地引发到调用线程(在sync命令中)。对于异步命令,Result属性枚举值可以包含一个额外的值:OK,Fail,Fault或Exception,回调可以通过命令对象的Exception属性访问实际的异常对象。

您对此策略有何看法?我很想不再为同步命令引发异常,只是在内部记录异常并返回第4个枚举值,因为在任何给定的情况下,我都会用异常来处理......或者,我应该不使用结果代码,只是在所有情况下引发异常,甚至是故障?

感谢。

有帮助吗?

解决方案

我认为你的策略基本上是合理的。

请记住,例外的目的是处理异常情况。越接近问题的根源,越好。

在您的情况下,您的策略似乎是“它现在无法正常工作”。让我们重试“。我没有理由提出异常。

如果处理一个封闭的套接字是需要在代码中完全不同的流程的东西,那么也许异常是有意义的。根据你的描述,情况并非如此。

我对例外的理念是,它们应该是你无法真正处理的特殊条件。一个封闭的插座?嗯......互联网在我家里停了多少次......

其他提示

我的偏好是你的方法没有成功完成任务时抛出异常。因此,如果我,调用者,调用yourObject.UploadFile(),我将假设在调用返回时文件已成功上载。如果它因任何原因失败,我希望你的对象会抛出异常。如果你想区分我可以重试的命令和我不应该重试的命令,把这些信息放在异常中我可以决定如何做出相应的反应。

当调用yourObject.BeginAsyncUploadFile()时,我会期望相同的行为,除了我需要等待IAsyncResult或等效对象以确定文件上载是否成功然后检查异常/错误财产,如果没有。

结果代码和例外都可以正常工作。这是个人品味的问题(以及团队中其他人的品味)。例外有一些优点,特别是在更复杂的设置中,但在你的设置中听起来很简单,返回代码应该可以正常工作。

有些人会在口中泡沫并坚持异常,但在我的项目中,人们喜欢简单的返回码,使它们成为更好的选择。

这是一个相当有趣的问题。因此,可能没有“100%正确”的答案,而且主要取决于您认为使用您的函数的代码应如何构建。

我看到它的方式是,只有当你想提供调用你的函数的代码时才能使用异常,以便从“灾难性”的情况中优雅地逃脱。所以,在我的代码中,我通常会在事情真的发生异常,真的可怕发生,并且调用者需要知道。

现在,如果您拥有的是正常和预期的情况,您应该返回错误值。这样代码就知道它需要“更加努力”,但不会因为发生的事情而受到影响。

在您的情况下,例如,您可以将超时视为预期的事情,从而返回错误代码,以及更严重的问题(如完整的发送缓冲区),其中调用代码需要执行一些额外的操作才能返回将'正常'作为例外。

然而,美丽是旁观者的眼睛,有些人会告诉你只使用例外,其他人(主要是C程序员)只使用返回码。请记住,异常始终是例外。 :)

许可以下: CC-BY-SA归因
不隶属于 StackOverflow
scroll top