代码之家 › 专栏 › 技术社区 › AZ.

异常或错误代码枚举

exception-handling exception .net

2

AZ. · 技术社区 · 16 年前

// 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();
        // ...
    }
}

5 回复 | 直到 16 年前

1

2

G-Wiz RameshVel 16 年前

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

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

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

2

1

Brian Agnew 16 年前

我会使用异常,当发生了非常糟糕的事情,以至于您无法继续使用该组件(或子组件等)时 没有一些补救措施

这是控制程序流吗?显然是的(任何例外情况都是如此)。但一个有效的问题是 这有多特别 ?

3

0

Oakcool 16 年前

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

4

0

fyjham 16 年前

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

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

5

0

Lightman 11 年前

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

在本例中没有理由使用exception。

归来 enum OpenResult { Openned, DLLFailed } 从 Open 方法。这对呼叫者来说已经足够了 打开 方法了解发生的情况并采取相应的行动。