我有一个封装了与服务器的TCP套接字通信的类。对于发送到服务器的每条命令消息，服务器将发回始终包含响应代码(确定，失败)的响应消息。使用我的课程，每个命令都可以同步或者异步执行。

基本上可以发生两种类型的异常：由断开连接或者某些其他不可恢复的错误引起的"故障"，以及诸如"发送缓冲区已满"的意外异常。如果发生故障，在重新建立连接之前，任何命令都无法继续执行或者重试。如果响应失败甚至异常，可以再次尝试该命令...

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

我们如何看待这种策略？我很想根本不引发同步命令的异常，而只是在内部记录该异常并返回第4个枚举值，因为无论如何在任何给定的情况下，我都会对异常进行真正的处理……或者，我不应该使用结果代码，是否在所有情况下都引发异常，甚至是错误？

谢谢。

解决方案

结果代码和异常都可以正常工作。这是个人喜好(以及团队中其他人的喜好)的问题。异常具有一些优点，尤其是在更复杂的设置中，但是在设置中，听起来很简单，以至于返回代码应该可以正常工作。

有些人会冒昧地坚持要求例外，但是在我的项目中，人们喜欢返回代码的简单性，使它们成为总体上更好的选择。

我认为策略基本上是正确的。

请记住，例外的目的是处理特殊情况。问题的根源越近越好。

在情况下，策略似乎类似于"目前不起作用。让我们重试"。我认为没有理由提出例外。

如果处理封闭的套接字需要在代码中使用完全不同的流程，那么异常可能有意义。根据描述，事实并非如此。

我对异常的看法是，异常应该用于我们无法真正处理的异常条件。封闭的插座？嗯...我家的互联网中断了多少次...

这是一个相当有趣的问题。因此，可能没有" 100％正确"的答案，并且主要取决于我们如何看待使用函数的代码的结构。

我的看法是，仅当我们希望为调用函数的代码提供一种可以从"灾难性"情况中正常退出的方法时，才使用异常。因此，在我的代码中，当发生确实非常可怕的事情并且调用者需要知道时，我通常会引发异常。

现在，如果我们所拥有的是正常的预期情况，则可能应该返回一个错误值。这样，代码知道需要"加倍努力"，但不会因发生的事情而受到损害。

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

但是随后，情人眼中就出现了美丽，有些人会告诉我们仅使用异常，而其他人(大多数是C程序员)将仅使用返回码。请记住，例外应该总是例外。 :)

我的偏爱是，只要方法未成功完成其任务，我们都将抛出异常。因此，如果我(调用方)调用yourObject.UploadFile()，则我将假定在调用返回时文件已成功上传。如果由于任何原因失败，我希望对象将引发异常。如果我们想区分我可以重试的命令和我不应该重试的命令，请将这些信息放在例外中，然后我可以决定如何做出相应的反应。

调用yourObject.BeginAsyncUploadFile()时，除了希望在IAsyncResult或者同等对象上等待以确定文件上传是否成功然后检查Exception / Error属性外，我希望具有相同的行为。没有。