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