É uma boa abordagem chamar o retorno interno usando a instrução {}?

Só quero saber se é seguro / bom fazer chamadas returndentro de um usingbloco.

Por ex.

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

Sabemos que a última chave dispose()será cancelada. Mas o que será no caso acima, já que returnsalta o controle do escopo dado (AFAIK) ...

1. É meu scope.Complete()chamado?
2. E assim, para o dispose()método do osciloscópio .

É perfeitamente seguro chamar returndentro do seu usingbloco, uma vez que um bloco em uso é apenas umtry/finally bloco.

Em seu exemplo acima, após o retorno true, o escopo será descartado e o valor retornado. return false, e nãoscope.Complete() será chamado.Disposeno entanto, será chamado independentemente, pois reside dentro do bloco finally.

Seu código é essencialmente o mesmo (se isso o tornar mais fácil de entender):

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();
}

Esteja ciente de que sua transação nunca será confirmada, pois não há como fazer scope.Complete()para confirmar a transação.

Tudo bem - finallycláusulas (que é o que a chave de fechamento dousing cláusula faz sob o capô) sempre são executadas quando o escopo é deixado, não importa como.

No entanto, isso só é verdadeiro para as instruções que estão no bloco finally (que não podem ser explicitamente definidas ao usar using ). Portanto, no seu exemplo, scope.Complete()nunca seria chamado (espero que o compilador avise sobre código inacessível).

Em geral, é uma boa abordagem. Mas, no seu caso, se você retornar antes de chamar o scope.Complete(), isso irá destruir o TransactionScope. Depende do seu design.

Portanto, neste exemplo, Complete () não é chamado e o escopo é descartado, supondo que ele herde a interface IDisposable.

scope.Complete definitivamente deve ser chamado antes return. O compilador exibirá um aviso e esse código nunca será chamado.

Quanto a returnsi mesmo - sim, é seguro chamá-lo de usingdeclaração interna . O uso é traduzido para tentar finalmente bloquear nos bastidores e finalmente bloquear deve ser executado.

No exemplo que você forneceu, há um problema; scope.Complete()nunca é chamado. Em segundo lugar, não é uma boa prática usar returninstrução dentro de usinginstruções. Consulte o seguinte:

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

Neste exemplo simples, o ponto é isso; o valor descope será nulo quando o uso da instrução for concluído.

Portanto, é melhor não voltar para dentro usando instruções.

Para certificar-se de que scope.Complete()será chamado, envolva-o com try/finally. O disposeé chamado porque você o envolveu com o usingque é um try/finallybloco alternativo .

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

Neste exemplo, scope.Complete () nunca será executado. No entanto, o comando de retorno limpará tudo o que está atribuído na pilha. O GC cuidará de tudo o que não for referenciado. Então, a menos que haja um objeto que não possa ser pego pelo GC, não há problema.