Perché un metodo che restituisce un valore bool / int e ha l'oggetto reale come parametro di output?

Vedo il seguente schema di codice ovunque nella base di codice della mia azienda (applicazione .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
}

Sto cercando di capire perché dovresti fare questo invece di avere il Foometodo semplicemente prendere l'ID e restituire un Bazoggetto, invece di restituire un valore non utilizzato e avere l'oggetto reale come parametro ref o output.

C'è qualche vantaggio nascosto di questo stile di codifica che mi manca?

Di solito usi quel modello in modo da poter scrivere codice in questo modo:

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

viene utilizzato nel CLR per TryGetValue nella classe del dizionario, ad esempio. Evita un po 'di ridondanza ma i parametri out e ref mi sono sempre sembrati un po' confusi

Questo è il vecchio codice in stile C, prima che ci fossero eccezioni. Il valore restituito indica se il metodo ha avuto esito positivo o meno e, in caso affermativo, il parametro verrebbe riempito con il risultato.

In .net abbiamo eccezioni a tale scopo. Non ci dovrebbero essere motivi per seguire questo schema.

[modifica] Ovviamente ci sono implicazioni sulle prestazioni nella gestione delle eccezioni. Forse questo ha qualcosa a che fare con questo. Tuttavia, in quel frammento di codice è già stata generata un'eccezione. Sarebbe più pulito lasciarlo salire nello stack fino a quando non viene catturato in un posto più appropriato.

Dato lo snippet di codice sembra completamente inutile. Per me il modello di codice iniziale suggerirebbe che null per BazObject sarebbe un caso accettabile e il ritorno bool è una misura per determinare in modo sicuro un caso fallito. Se il seguente codice era:

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

Ciò avrebbe più senso per me farlo in questo modo. Forse questo è un metodo che qualcuno prima di te stava usando per garantire che il baz fosse passato per riferimento senza capire come i parametri dell'oggetto funzionino effettivamente in C #.

A volte questo schema è utile quando tu, il chiamante, non dovresti preoccuparti se il tipo restituito è un tipo di riferimento o valore. Se si chiama un metodo di questo tipo per recuperare un tipo di valore, quel tipo di valore avrà bisogno di un valore non valido stabilito (ad es. Double.NaN) o è necessario un altro modo per determinare il successo.

L'idea è di restituire un valore che indica se il processo ha avuto esito positivo, consentendo un codice come questo:

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

Se l'oggetto non può essere nullo (che appare corretto nel tuo esempio), è meglio farlo come segue:

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

Se l'oggetto può essere nullo, le eccezioni sono la strada da percorrere:

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

È un modello comune usato in C, dove non ci sono eccezioni. Consente alla funzione di restituire una condizione di errore. Le eccezioni sono generalmente una soluzione molto più pulita.