try / catch + using, właściwa składnia

Który:

using (var myObject = new MyClass())
{
   try
   {
      // something here...
   }
   catch(Exception ex)
   {
      // Handle exception
   }
}

LUB

try
{
   using (var myObject = new MyClass())
   {
      // something here...
   }
}
catch(Exception ex)
{
   // Handle exception
}

Wolę drugi. Może również uwięzić błędy związane z tworzeniem obiektu.

Ponieważ blok używający jest po prostu uproszczeniem składni try / wreszcie ( MSDN ), osobiście wybrałbym następujące, choć wątpię, aby znacznie różniło się od twojej drugiej opcji:

MyClass myObject = null;
try {
  myObject = new MyClass();
  //important stuff
} catch (Exception ex) {
  //handle exception
} finally {
  if(myObject is IDisposable) myObject.Dispose();
}

To zależy. Jeśli korzystasz z Windows Communication Foundation (WCF), using(...) { try... }nie będzie działać poprawnie, jeśli serwer proxy w usinginstrukcji jest w stanie wyjątku, tzn. Usunięcie tego serwera proxy spowoduje kolejny wyjątek.

Osobiście wierzę w minimalne podejście do obsługi, tj. Obsługuj tylko wyjątki, o których wiesz w momencie wykonania. Innymi słowy, jeśli wiesz, że inicjalizacja zmiennej usingmoże wywołać określony wyjątek, to ją zawijam try-catch. Podobnie, jeśli w usingciele może się zdarzyć coś, co nie jest bezpośrednio związane ze zmienną w using, to zawijam to innym trydla tego wyjątku. Rzadko używam Exceptionw swoimcatch es.

Ale mi się podoba IDisposablei usingmoże dlatego jestem stronniczy.

Jeśli instrukcja catch musi uzyskać dostęp do zmiennej zadeklarowanej w instrukcji using, wówczas wewnątrz jest twoją jedyną opcją.

Jeśli instrukcja catch potrzebuje obiektu, do którego istnieje odwołanie, zanim zostanie usunięta, wówczas wewnątrz jest twoją jedyną opcją.

Jeśli instrukcja catch podejmie działanie o nieznanym czasie trwania, np. Wyświetli komunikat dla użytkownika, a chcesz zutylizować swoje zasoby, zanim to nastąpi, wtedy najlepszym rozwiązaniem jest wyjście na zewnątrz.

Ilekroć mam scenerię podobną do tej, blok try-catch jest zwykle w innej metodzie w górę stosu wywołań niż za pomocą. Nie jest typowe dla tej metody, aby wiedzieć, jak obsługiwać wyjątki, które występują w niej w ten sposób.

Więc moja ogólna rekomendacja jest na zewnątrz - na zewnątrz.

private void saveButton_Click(object sender, EventArgs args)
{
    try
    {
        SaveFile(myFile); // The using statement will appear somewhere in here.
    }
    catch (IOException ex)
    {
        MessageBox.Show(ex.Message);
    }
}

Obie są poprawną składnią. To naprawdę sprowadza się do tego, co chcesz zrobić: jeśli chcesz wyłapać błędy związane z tworzeniem / usuwaniem obiektu, użyj drugiego. Jeśli nie, użyj pierwszego.

Przywołam tutaj jedną ważną rzecz: pierwsza nie złapie żadnego wyjątku wynikającego z wywołania MyClasskonstruktora.

Od C # 8.0 wolę używać tego samego w ten sam sposób

public class Person : IDisposable
{
    public Person()
    {
        int a = 0;
        int b = Id / a;
    }
    public int Id { get; set; }

    public void Dispose()
    {
    }
}

i wtedy

static void Main(string[] args)
    {

        try
        {
            using var person = new Person();
        }
        catch (Exception ex) when
        (ex.TargetSite.DeclaringType.Name == nameof(Person) &&
        ex.TargetSite.MemberType == System.Reflection.MemberTypes.Constructor)
        {
            Debug.Write("Error Constructor Person");
        }
        catch (Exception ex) when
       (ex.TargetSite.DeclaringType.Name == nameof(Person) &&
       ex.TargetSite.MemberType != System.Reflection.MemberTypes.Constructor)
        {
            Debug.Write("Error Person");
        }
        catch (Exception ex)
        {
            Debug.Write(ex.Message);
        }
        finally
        {
            Debug.Write("finally");
        }
    }

Jeśli obiekt, który inicjujesz w bloku Using (), może zgłosić wyjątek, powinieneś przejść do drugiej składni, w przeciwnym razie obie są równie poprawne.

W moim scenariuszu musiałem otworzyć plik i przekazałem filePath do konstruktora obiektu, który inicjowałem w bloku Using (), i może wygenerować wyjątek, jeśli filePath jest niepoprawny / pusty. W tym przypadku druga składnia ma sens.

Mój przykładowy kod: -

try
{
    using (var obj= new MyClass("fileName.extension"))
    {

    }
}
catch(Exception ex)
{
     //Take actions according to the exception.
}

Od wersji C # 8.0 możesz uprościćusing instrukcje pod pewnymi warunkami, aby pozbyć się zagnieżdżonego bloku, a następnie dotyczy to tylko otaczającego bloku.

Twoje dwa przykłady można sprowadzić do:

using var myObject = new MyClass();
try
{
   // something here...
}
catch(Exception ex)
{
   // Handle exception
}

I:

try
{
   using var myObject = new MyClass();
   // something here...
}
catch(Exception ex)
{
   // Handle exception
}

Oba są dość jasne; a następnie ogranicza to wybór między nimi do kwestii tego, jaki ma być zakres obiektu, gdzie chcesz obsługiwać błędy instancji i kiedy chcesz go pozbyć.