.net 异常或错误代码枚举

最近，我正在重构一个.net程序，它将使用自定义usb设备。该设备带有用于通信的dll。dll是用c编写的，通过检查标头，它定义了一组错误返回码

与设备通信的第一步是打开设备

在dll中，open函数如下所示：

// return different codes, such as OK, ERROR_CANNOT_CLAIM_INTERFACE, etc.  
int DLL_Open();

在.net程序中，它对错误代码使用异常：

// Return true if succeed. Throw exception if there is error.
bool Open()
{
    int flag = DLL_Open();
    if(flag == OK) return true;
    else
    {
        if(flag == ERROR_CANNOT_CLAIM_INTERFACE)
            throw USBException();
        // ...
    }
}

---

我的问题是，为什么要使用异常而不是简单地使用错误代码作为dll API？我读了一些提到“不要使用异常来控制应用程序流”的文章，我认为这里的异常有点像控制流。

返回代码不会影响执行流。您可以随意忽略返回代码，而必须主动捕获并忽略异常

我会使用例外情况，如果发生了非常糟糕的事情，如果不采取一些补救措施，您就无法继续使用该组件（或子组件等）——在本例中，插入U盘

---

这是控制程序流吗？显然是的（任何例外情况都是如此）。但一个有效的问题是这有多例外？

例外是处理错误的一种体面的方式，您可以使用其他表单（例如：GOTO），但它并不好。我也不同意不使用它来控制流的想法。。。显然，我所说的流是一个非常低的入侵流，您应该根据异常来排列大量的决策，但是您可以根据特定类型的异常定义不同的操作和流。

---

这也是一种引发错误的好方法。

这两种解决方案都有效，枚举提供了更好的性能，异常可能提供更好的解耦（跨系统边界）。这实际上是一个软件设计和惯例的问题。如果您正在处理的系统的功能范围不包括处理给定的错误条件，则基本上使用异常

如果此.NET程序有自己的UI，则不需要抛出异常。使用枚举并向用户显示错误。另一方面，如果这个.NET程序是供第三方使用的程序集，则认为更传统的做法是不在API中公开错误代码或枚举，而是抛出（和记录）异常

---

中间立场是，这个程序没有自己的UI，但它被另一个系统使用，而你（或你组织中的某个人）也可以控制这个系统。在这种情况下，您可以选择任何一种方式，枚举提供更好的性能，异常提供更好的解耦。

归结为一个非常简单的问题：发生这种情况是典型的程序流吗

您不希望代码的标准条件逻辑由异常控制，但另一方面，如果是真正的错误情况，则抛出适当类型的异常是最好的方法。这实际上取决于事件是调用函数的预期结果还是罕见的边缘案例错误。有时两者都做是有意义的，将预期结果作为枚举公开，但仍将实际错误作为例外

从性能角度来看，异常模型使用了大量的处理能力，但只有在抛出异常时才使用。如果没有错误，它实际上比使用枚举更快。如果您真的想了解这种性能，那么查找Int32.Parse vs Int32.TryParse上的信息可能是最有用的（第一个使用了异常模型，他们添加了第二个以提高性能，因为人们经常在未验证的数据上使用它）

为什么要使用异常而不是简单地使用错误代码作为dll API

在本例中没有理由使用exception

只需从

Open

方法返回

enum OpenResult{Openned，DLLFailed}

。这将足以让

Open

方法的调用者理解发生了什么，并采取相应的行动