我有一个类封装了与服务器的tcp套接字通信。对于发送到服务器的每条命令消息，服务器将发回一条响应消息，该响应消息总是包含响应代码（OK，Fail）。使用我的类，每个命令都可以执行同步或异步。
基本上可以发生两种类型的异常：由断开连接或其他一些不可恢复的错误引起的“故障”以及“发送缓冲区已满”等意外异常。如果发生故障，在重新建立连接之前，任何命令都不能继续或再次尝试。如果发生故障响应甚至异常，可以再次尝试该命令......
所以，现在我的sync命令方法返回一个可以包含以下值的枚举：OK，Fail，Fault。如果发生异常，则将其简单地引发到调用线程（在sync命令中）。对于异步命令，Result属性枚举值可以包含一个额外的值：OK，Fail，Fault或Exception，回调可以通过命令对象的Exception属性访问实际的异常对象。
您对此策略有何看法？我很想不再为同步命令引发异常，只是在内部记录异常并返回第4个枚举值，因为在任何给定的情况下，我都会用异常来处理......或者，我应该不使用结果代码，只是在所有情况下引发异常，甚至是故障？
感谢。
答案 0 :(得分：1)
我认为你的策略基本上是合理的。
请记住，例外的目的是处理异常情况。越接近问题的根源，越好。
在您的情况下，您的策略似乎是“它现在无法正常工作。让我们重试”。我没有理由提出异常。
如果处理一个封闭的套接字是需要在代码中完全不同的流程的东西，那么也许异常是有意义的。根据你的描述，情况并非如此。
我对例外的理念是，它们应该是你无法真正处理的特殊条件。一个封闭的插座？嗯......互联网在我家里停了多少次......
答案 1 :(得分：1)
我的偏好是你的方法没有成功完成任务时抛出异常。因此，如果我，调用者，调用yourObject.UploadFile（），我将假设在调用返回时文件已成功上载。如果它因任何原因失败，我希望你的对象会抛出异常。如果你想区分我可以重试的命令和我不应该重试的命令，把这些信息放在异常中我可以决定如何做出相应的反应。
当调用yourObject.BeginAsyncUploadFile（）时，我会期望相同的行为，除了我需要等待IAsyncResult或等效对象以确定文件上载是否成功然后检查异常/错误财产，如果没有。
答案 2 :(得分：0)
结果代码和例外都可以正常工作。这是个人品味的问题（以及团队中其他人的品味）。例外有一些优点，特别是在更复杂的设置中，但在你的设置中听起来很简单，返回代码应该可以正常工作。
有些人会在口中泡沫并坚持异常，但在我的项目中，人们喜欢简单的返回码，使它们成为更好的选择。
答案 3 :(得分：0)
这是一个相当有趣的问题。因此，可能没有“100％正确”的答案，而且主要取决于您认为使用您的函数的代码应如何构建。
我看到它的方式是，只有当你想提供调用你的函数的代码时才能使用异常，以便从“灾难性”的情况中优雅地逃脱。所以，在我的代码中，我通常会在事情真的发生异常，真的可怕发生，并且调用者需要知道。
现在，如果您拥有的是正常和预期的情况，您应该返回错误值。这样代码就知道它需要“更加努力”，但不会因为发生的事情而受到影响。
在您的情况下，例如，您可以将超时视为预期的事情，从而返回错误代码，以及更严重的问题（如完整的发送缓冲区），其中调用代码需要执行一些额外的操作才能返回将'正常'作为例外。
然而，美丽是旁观者的眼睛，有些人会告诉你只使用例外，其他人（主要是C程序员）只使用返回码。请记住，异常始终是例外。 ：）