Чому є метод, який повертає 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 в класі словника. Це дозволяє уникнути надмірності, але параметри та параметри для мене завжди здавалися делікатними

Це старий код стилю C, раніше були винятки. Повернене значення вказувало, чи був метод успішним чи ні, і якщо він був, параметр буде заповнений результатом.

У .net у нас є винятки для цієї мети. Не повинно бути причин слідувати цій схемі.

[редагувати] Очевидно, що в роботі з виключеннями є ефективність. Можливо, це має щось спільне з цим. Однак у цьому фрагменті коду вже є виняток. Було б чистіше просто дозволити йому переміщатися вгору по стеку, поки він не потрапить у більш відповідне місце.

З огляду на фрагмент коду, він виглядає абсолютно безглуздо. Для мене початкова схема коду підказує, що null для BazObject буде прийнятним випадком, а повернення 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
}

Для цього було б більше сенсу робити це так. Можливо, це метод, який хтось перед вами використовував, щоб гарантувати, що база передається посиланням, не розуміючи, як параметри об’єкта насправді працюють у 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, де немає винятків. Це дозволяє функції повернути стан помилки. Винятки, як правило, набагато чистіші рішення.