Question

最近我正在重构一个将使用自定义USB设备的.net程序。该设备带有一个用于通信的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？我读了一些文章“不要使用异常来控制应用程序流”，我认为这里的例外就像控制流程一样。

Answer 1

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

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

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

Answer 2

返回代码不会影响执行流程。您可以自由地忽略返回代码，而必须主动捕获和忽略异常。

我会利用例外情况发生了一些非常糟糕的事情，以至于你不能继续使用那个组件（或子组件等）而没有一些补救措施 - 在这种情况下堵塞USB记忆棒。

这个控制程序是否流动？显然是的（任何例外）。但是一个有效的问题是这个有多么特殊？

Answer 3

异常是一种处理错误的好方法，你可以使用其他形式（例如：GOTO），但这并不好。我也不同意不使用它做控制流程的想法......显然，我所说的流程是一个非常低的入侵流程，你应该根据异常来判断所有决策，但你可以定义不同的行动和流动取决于某些类型的例外。也是冒泡错误的好方法。

Answer 4

这归结为一个非常简单的问题：这是典型的程序流程吗？

您不希望代码的标准条件逻辑由异常控制，但另一方面，如果它是真正的错误情况，那么抛出适当类型的异常是最好的方法。它确实归结为事件是否是调用函数的预期结果或罕见的边缘情况错误。有时甚至将两者都做成有意义，将预期结果作为枚举公开，但仍将实际错误视为例外。

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

Answer 5

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

在此示例中没有理由使用异常。

只需从enum OpenResult { Openned, DLLFailed }方法返回Open即可。这对于Open方法的调用者来说足以理解发生的事情并采取相应的行动。

异常或错误代码枚举

5 个答案: