Почему есть метод, который возвращает 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метод просто взял идентификатор и возвратил Bazобъект, вместо того, чтобы возвращать значение, которое не используется, и иметь фактический объект как параметр ref или output.

Есть ли какая-то скрытая выгода от этого стиля кодирования, который мне не хватает?

Вы обычно используете этот шаблон, чтобы написать код следующим образом:

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

например, он используется в CLR для TryGetValue в классе словаря. Это позволяет избежать некоторой избыточности, но параметры out и ref всегда казались мне немного беспорядочными

Это старый код в стиле C, до того, как возникли исключения. Возвращаемое значение указывает, был ли метод успешным или нет, и если это так, параметр будет заполнен результатом.

В .net у нас есть исключения для этой цели. Не должно быть никаких причин следовать этой схеме.

[edit] Очевидно, что это влияет на производительность при обработке исключений. Может быть, это как-то связано с этим. Однако в этом фрагменте кода уже выдается исключение. Было бы чище просто позволить ему двигаться вверх по стеку, пока он не окажется в более подходящем месте.

Учитывая фрагмент кода, это выглядит совершенно бессмысленно. Для меня исходный шаблон кода предполагает, что для BazObject допустимым является случай null, а возврат bool является мерой безопасного определения случая сбоя. Если следующий код был:

// 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!");
}

Если объект не может быть нулевым (что кажется правильным в вашем примере), лучше сделать это следующим образом:

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

Если объект может быть нулевым, исключения - это путь:

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

Это общий шаблон, используемый в C, где нет исключений. Это позволяет функции возвращать состояние ошибки. Исключения, как правило, гораздо более чистое решение.