异常或错误代码枚举

最近我重构将使用专用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？我读提到“不要使用异常来控制应用程序流”的一些文章，我觉得这里的例外是那种喜欢控制流量。

来源

2009-11-25 AZ.

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

如果这个.NET程序有它自己的用户界面，你不需要抛出异常。使用枚举并向用户显示错误。在另一方面，如果这个.NET程序是由第三方使用的组件，它被认为是更传统的不暴露错误代码或枚举的API中，而是扔（和文件）例外。

的中间地带将是这个程序没有它自己的用户界面，但它是由你也（或者有人在你的组织中）具有控制另一台系统消耗。在这种情况下，你可以采用任何方式，枚举提供更好的性能，异常提供更好的解耦。

来源

2009-11-25 19:15:49

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

我会做异常的使用，其中一些足够糟糕的事情，这样你可以没有一些补救措施使用该组件携带（或子组件等）- 在这种情况下，插入USB棒。

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

来源

2009-11-25 19:07:00

异常是一种体面的处理错误的方式，你可以使用其他形式（例如：GOTO），但它不好。我也不会与不使用它做控制流......显然，我说的流动是一个非常低的入侵流量，你应该艾琳的所有基于异常的决策zilions的想法一致，但可以定义不同行动和流程取决于某些特例。也就是冒泡错误的好办法。

来源

2009-11-25 19:07:51 Oakcool

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

你不希望你的代码的标准条件逻辑被异常控制，但另一方面，如果它是一个真正的错误情况则抛出适当类型的例外是最好的一段路要走。它确实涉及事件是否是调用函数的预期结果或罕见的边缘错误。有时甚至是有意义的做到这一点，将预期的结果作为枚举暴露出来，但仍然将实际错误作为例外情况。

从性能角度来看，异常模型使用的处理能力更强大，但只有在引发异常时才会如此。如果没有错误，实际上比使用枚举更快。如果你真的想看看这个表现，那么寻找关于Int32.Parse和Int32.TryParse的信息可能有最多的信息（第一个使用异常模型，他们增加了第二个以提高性能，因此人们经常使用它未验证的数据）。

来源

2009-11-25 21:25:37 fyjham

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

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

只需从Open方法返回enum OpenResult { Openned, DLLFailed }方法。对于Open方法的调用者来说，这足以了解发生了什么并据此采取行动。

来源

2015-08-30 11:17:35 Lightman

异常或错误代码枚举

回答

相关问题