为什么要有一个返回bool / int并将实际对象作为输出参数的方法？

我在公司代码库（.NET 3.5应用程序）的各处看到以下代码模式：

bool Foo(int barID, out Baz bazObject) { 
    try { 
            // do stuff
            bazObject = someResponseObject;

            return true;
    }
    catch (Exception ex) { 
        // log error
        return false;
    }
}

// calling code
BazObject baz = new BazObject();
fooObject.Foo(barID, out baz);

if (baz != null) { 
    // do stuff with baz
}

我试图绕开为什么要这样做，而不是让Foo方法简单地获取ID并返回一个Baz对象，而不是返回未使用的值并使实际对象成为ref或output参数，这是我的头绪。

我缺少这种编码样式的一些隐藏优势吗？

您通常使用该模式，因此可以编写如下代码：

if (Foo(barId, out bazObject))
{
  //DoStuff with bazobject
}

例如，它在字典类的CLR中用于TryGetValue。它避免了一些冗余，但是out和ref参数在我看来总是有些混乱

在出现异常之前，这是旧的C样式代码。返回值指示该方法是否成功，如果成功，则将用结果填充参数。

在.net中，我们为此有例外。应该没有理由遵循这种模式。

[edit]异常处理显然对性能有影响。也许与它有关。但是，在该代码段中已经抛出了异常。只是让它在堆栈中向上移动直到被卡在更合适的位置，这样会更清洁。

给定代码段，它看起来完全没有意义。对我而言，初始代码模式将建议BazObject的null为可接受的情况，并且布尔返回值是安全确定失败情况的一种措施。如果以下代码是：

// calling code
BazObject baz = new BazObject();
bool result = fooObject.Foo(barID, out baz);

if (result) { 
    // do stuff with baz
    // where baz may be 
    // null without a 
    // thrown exception
}

这样对我来说更有意义。也许这是您之前用来确保通过引用传递baz而不了解对象参数在C＃中实际工作方式的一种方法。

有时，当您（调用方）不关心返回的类型是引用类型还是值类型时，此模式很有用。如果要调用这样的方法来检索值类型，则该值类型将需要一个已建立的无效值（例如，double.NaN），或者需要其他确定成功的方法。

这个想法是返回一个值，该值指示该过程是否成功，并允许如下代码：

Baz b;
if (fooObject.foo(id, out b)) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

如果对象不能为null（在您的示例中显示为正确），则最好执行以下操作：

Baz b = fooObject.foo(id);
if (b != null) {
   // do something with b
}
else {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

如果对象可以为null，则可以使用异常处理：

try {
   Baz b = fooObject.foo(id);
}
catch (BazException e) {
   Error.screamAndRun("object lookup/whatever failed! AAaAAAH!");
}

这是C语言中常用的模式，没有例外。它允许函数返回错误条件。通常，例外是更干净的解决方案。