Dlaczego metoda, która zwraca bool / int i ma rzeczywisty obiekt jako parametr wyjściowy?

W bazie danych mojej firmy (aplikacja .NET 3.5) widzę następujący wzór kodu:

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
}

Staram się owijać wokół głowy, dlaczego miałbyś to zrobić zamiast tego, że Foometoda po prostu bierze identyfikator i zwraca Bazobiekt, zamiast zwracać wartość, która nie jest używana, a faktycznym obiektem jest parametr referencyjny lub wyjściowy.

Czy jest jakaś ukryta zaleta tego stylu kodowania, którego mi brakuje?

Zwykle używasz tego wzorca, aby móc pisać kod w ten sposób:

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

jest używany na przykład w CLR dla TryGetValue w klasie słownikowej. Pozwala to uniknąć nadmiarowości, ale parametry out i ref zawsze wydawały mi się nieco niechlujne

Jest to stary kod w stylu C, zanim były wyjątki. Zwracana wartość wskazuje, czy metoda zakończyła się powodzeniem, czy nie, a jeśli tak, parametr zostanie wypełniony wynikiem.

W .net mamy wyjątki w tym celu. Nie powinno być żadnego powodu, aby stosować ten wzór.

[edytuj] Oczywiste są skutki wydajności w obsłudze wyjątków. Może to ma z tym coś wspólnego. Jednak w tym fragmencie kodu jest już zgłaszany wyjątek. Byłoby czystsze pozwolić po prostu przesuwać się w górę stosu, dopóki nie zostanie złapany w bardziej odpowiednim miejscu.

Biorąc pod uwagę fragment kodu, wygląda to zupełnie bezcelowo. Według mnie początkowy wzorzec kodu sugerowałby, że null dla BazObject byłby dopuszczalnym przypadkiem, a powrót bool jest miarą bezpiecznego określenia przypadku niepowodzenia. Jeśli następujący kod to:

// 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
}

To miałoby dla mnie większy sens, aby zrobić to w ten sposób. Być może jest to metoda, której ktoś wcześniej używał, aby zagwarantować, że baz był przekazywany przez referencję, nie rozumiejąc, jak parametry obiektu faktycznie działają w języku C #.

Czasami ten wzorzec jest przydatny, gdy osoba dzwoniąca nie powinna dbać o to, czy zwracany typ jest typem referencyjnym czy wartościowym. Jeśli wywołujesz taką metodę w celu pobrania typu wartości, ten typ wartości będzie albo potrzebował ustalonej niepoprawnej wartości (np. Double.NaN), albo potrzebujesz innego sposobu ustalenia sukcesu.

Pomysł polega na zwróceniu wartości wskazującej, czy proces się powiódł, umożliwiając następujący kod:

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

Jeśli obiekt nie może mieć wartości NULL (co w twoim przykładzie wygląda poprawnie), lepiej zrobić to w następujący sposób:

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

Jeśli obiekt może mieć wartość NULL, możliwe są wyjątki:

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

Jest to powszechny wzorzec używany w C, gdzie nie ma wyjątków. Pozwala to funkcji zwrócić błąd. Wyjątki są ogólnie o wiele czystszym rozwiązaniem.