Question

我有一个控制流问题。在我的公司，我们创建了许多bool方法，如果出现错误，则返回false。例如：

public bool Foo(string path, string fileName, ref string error)
{
    if (path == null)
    {
        error = "path is null";
        return false;
    }
    path += fileName;
    return true;
}

你可以看到它很难看。我希望使用它，例如：

public voidFoo(string path, string fileName, ref string error)
{
    if (path == null)
    {
        throw new SomeException("Path is null.");
    }
    path += fileName;
    return true;
}

但我们担心开销。我们应该吗？

Answer 1

如果异常不抛出，那么try...catch的开销可以忽略不计。所以，经验法则是：

如果异常可能被抛出（即，如果path == null是“支持”方案），请使用返回值。
如果异常不太可能，即如果path == null通常仅在使用您的函数的开发人员出错时才会发生，则使用例外。

Answer 2

永远不要将异常用作流量控制的一种形式。

通常，抛出异常比检查失败值要昂贵得多 - 在这种情况下，如果path永远不应该是假的并且预期永远存在，那么空path就是例外情况和异常应该抛出。

在方法设计方面 - 您不应该依赖调用方法来检查返回值。如果有人忘记检查，如果返回false会怎样？一个例外使得这个问题消失了，因为一些不好的事情发生了，你的代码停止运行。

Answer 3

例外是如何发生的？抛出和捕获异常会产生一些您可能不愿意在一般情况下使用的开销。

在风格上，出于性能和理解的原因，不赞成使用流控制的异常。如果这是（无双关语）异常发生，我会使用异常。如果性能是关键（你应该测量它 - premature optimisation being the root of all evil等），那么更优化的解决方案是使用返回值。

这种情况令人头疼的是，可能会忽略或误用返回值（通常为false或null。

Answer 4

例外情况应保留用于特殊情况，例如资源不可用等。磁盘空间或网络连接。

使用流量控制的例外是完全错误的，它没有正确的味道。

使用布尔返回码是一种方法。您还可以创建一个描述错误原因的错误对象，而不是通过引用返回。

Answer 5

所有书都说你应该使用例外信号错误。如果您使用if，那么50％的源代码行是关于返回错误消息的，并且很难阅读源代码并查看它是否无用。

仅在时间紧迫的情况下使用返回值，在这种情况下，您预计会发生许多错误，并且计算时间对您来说非常重要。

Answer 6

我喜欢异常。我只是做。当然，这取决于你的实施地点。

例如，我希望有一些非常基本的类来抛出异常，因为我不希望这些类有责任不抛弃它。

C＃的好处是你不必捕获每个异常，因为它只是在它出错时才会进一步抛出它。这样可以为您节省大量代码。另外还有布尔值：if false -> return false; if false -> return false;。我认为将是开销。

当然，在某些时候，你必须抓住你的例外，但这是实施者选择的地方。当然，你不需要一些巨大的捕获块，但只有在你想捕获它的时候，你应该抓住它。

我会去找它。

Answer 7

这取决于你认为“假”状态是否异常。或换句话说，通常不会出乎意料。

例如，如果将一个对象传递给一个方法，该方法对于该方法的工作是否为空而没有任何意义，那么也许你应该抛出一个ArgumentNullException：

public void Foo(object obj)
{
    if(obj == null) throw new ArgumentNullException("obj", "Object cannot be null.");

    //
}

C＃中的例外与“if”

7 个答案: