È un buon approccio chiamare return inside usando l'istruzione {}?

Voglio solo sapere se è sicuro / un buon approccio chiamare returnall'interno di un usingblocco.

Per es.

using(var scope = new TransactionScope())
{
  // my core logic
  return true; // if condition met else
  return false;
  scope.Complete();
}

Sappiamo che l'ultima doppietta più riccia dispose()verrà annullata. Ma cosa accadrà nel caso precedente, dal momento che returnsalta il controllo fuori dallo scopo dato (AFAIK) ...

1. Mi scope.Complete()viene chiamato?
2. E così per il dispose()metodo dell'ambito .

È perfettamente sicuro chiamare returnall'interno del tuo usingblocco, poiché un blocco using è solo un try/finallyblocco.

Nell'esempio precedente dopo la restituzione true, l'ambito verrà eliminato e il valore restituito. return falsee nonscope.Complete() verrà chiamato. tuttavia verrà chiamato a prescindere poiché risiede all'interno del blocco finalmente.Dispose

Il tuo codice è essenzialmente lo stesso di questo (se questo lo rende più facile da capire):

var scope = new TransactionScope())
try
{
  // my core logic
  return true; // if condition met else
  return false;
  scope.Complete();
}
finally
{
  if( scope != null) 
    ((IDisposable)scope).Dispose();
}

Si prega di essere consapevoli del fatto che la transazione non verrà mai impegnata in quanto non è possibile ottenere il scope.Complete()commit della transazione.

Va bene - le finallyclausole (che è ciò che fa la parentesi graffa di chiusura della usingclausola sotto il cofano) vengono sempre eseguite quando l'ambito viene lasciato, non importa come.

Tuttavia, questo è vero solo per le istruzioni che si trovano nel blocco finalmente (che non può essere impostato esplicitamente durante l'uso using). Pertanto, nel tuo esempio, scope.Complete()non verrebbe mai chiamato (mi aspetto che il compilatore ti avverta del codice non raggiungibile).

In generale, è un buon approccio. Ma nel tuo caso, se torni prima di chiamare scope.Complete(), verrà semplicemente cestinato il TransactionScope. Dipende dal tuo design.

Quindi, in questo esempio, Complete () non viene chiamato e l'ambito viene eliminato, supponendo che erediti l'interfaccia IDisposable.

Scope.Complete dovrebbe sicuramente essere chiamato prima return. Il compilatore visualizzerà un avviso e questo codice non verrà mai chiamato.

Riguardo a returnse stesso - sì, è sicuro chiamarlo usingdichiarazione interna . L'utilizzo è tradotto per provare finalmente a bloccare dietro le quinte e infine il blocco deve essere sicuramente eseguito.

Nell'esempio fornito, c'è un problema; scope.Complete()non viene mai chiamato. In secondo luogo, non è una buona pratica utilizzare returnistruzioni all'interno di usingdichiarazioni. Fare riferimento a quanto segue:

using(var scope = new TransactionScope())
{
    //have some logic here
    return scope;      
}

In questo semplice esempio, il punto è quello; il valore di scopesarà null quando l'istruzione using è terminata.

Quindi è meglio non tornare dentro usando le istruzioni.

Per assicurarti che scope.Complete()venga chiamato, avvolgilo con try/finally. Il disposesi chiama perché lo hai avvolto con il usingche è un try/finallyblocco alternativo .

using(var scope = new TransactionScope())
{
  try
  {
  // my core logic
  return true; // if condition met else
  return false;
  }
  finally
  {
   scope.Complete();
  }
}

In questo esempio, scope.Complete () non verrà mai eseguito. Tuttavia, il comando di ritorno pulirà tutto ciò che è assegnato nello stack. Il GC si prenderà cura di tutto ciò che non è referenziato. Quindi, a meno che non ci sia un oggetto che non può essere raccolto dal GC, non ci sono problemi.