Czy dobrym podejściem jest wywołanie funkcji return inside przy użyciu instrukcji {}?

Chcę tylko wiedzieć, czy dzwonienie returnwewnątrz usingbloku jest bezpieczne / dobre .

Na przykład.

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

Wiemy, że w końcu najbardziej zakręcony aparat dispose()zostanie odwołany. Ale co będzie w powyższym przypadku, skoro returnwyskakuje sterowanie poza podany zakres (AFAIK) ...

1. Czy moje scope.Complete()wezwanie?
2. I tak w przypadku metody lunety dispose().

Wykonywanie połączeń returnwewnątrz usingbloku jest całkowicie bezpieczne , ponieważ blok using to tylko try/finallyblok.

W powyższym przykładzie po powrocie truezakres zostanie usunięty, a wartość zwrócona. return falseI scope.Complete()będzie nie sprawdzony. Disposejednak zostanie wywołany niezależnie, ponieważ znajduje się wewnątrz ostatniego bloku.

Twój kod jest zasadniczo taki sam jak ten (jeśli to ułatwia zrozumienie):

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

Należy pamiętać, że transakcja nigdy nie zostanie zatwierdzona, ponieważ nie ma sposobu, aby scope.Complete()ją zatwierdzić.

W porządku - finallyklauzule (co robi zamykający nawias klamrowy usingklauzuli pod maską) zawsze są wykonywane po opuszczeniu zakresu, bez względu na sposób.

Jest to jednak prawdziwe tylko dla instrukcji, które znajdują się w ostatnim bloku (którego nie można jawnie ustawić podczas używania using). Dlatego w twoim przykładzie scope.Complete()nigdy nie zostałoby wywołane (oczekuję jednak, że kompilator ostrzeże Cię o nieosiągalnym kodzie).

Ogólnie jest to dobre podejście. Ale w twoim przypadku, jeśli wrócisz przed wywołaniem scope.Complete(), po prostu usunie to TransactionScope. Zależy od twojego projektu.

Tak więc w tym przykładzie Complete () nie jest wywoływana, a zakres jest usuwany, przy założeniu, że dziedziczy on interfejs IDisposable.

scope.Complete należy zdecydowanie wywołać wcześniej return. Kompilator wyświetli ostrzeżenie i ten kod nigdy nie zostanie wywołany.

Jeśli chodzi o returnsiebie - tak, można to bezpiecznie nazwać usingoświadczeniem wewnętrznym . Użycie jest tłumaczone na blok try-final za sceną i ostatecznie blok ma być z pewnością wykonany.

W podanym przykładzie występuje problem; scope.Complete()nigdy nie jest wezwany. Po drugie, nie jest dobrą praktyką stosowanie returninstrukcji wewnątrz usinginstrukcji. Zapoznaj się z następującymi informacjami:

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

W tym prostym przykładzie chodzi o to; wartośćscope will będzie zerowa po zakończeniu używania instrukcji.

Dlatego lepiej nie wracać do środka za pomocą instrukcji.

Aby upewnić się, że scope.Complete()zostanie wywołana, owiń ją try/finally. disposeNazywa bo trzeba zawinąć go z usingktóry jest alternatywą try/finallyblok.

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

W tym przykładzie scope.Complete () nigdy nie zostanie wykonana. Jednak polecenie return wyczyści wszystko, co jest przypisane na stosie. GC zajmie się wszystkim, do czego nie ma odniesienia. Więc jeśli nie ma przedmiotu, którego GC nie może odebrać, nie ma problemu.