Powrót w try & catch a zwrot w końcu?

Czy jedno z tych ryzykownych jest ryzykowne? Czy jest lepszy? A może to jedna z tych rzeczy, które wydrukujesz i rzucasz strzałką, aby zdecydować?Powrót w try & catch a zwrot w końcu?

chcę to zrobić teraz, kiedy wreszcie zrozumieć, jak działa:

try { 
    stuff that changes something... 
} 
catch (System.Exception ex) { 
    something.worked = false; 
    something.err = ex.Message; 
} 
finally { 
    stuff.close(); 
    return something; 
}

Ale widziałem:

try { 
    stuff that changes something... 
    return something; 
} 
catch (System.Exception ex) { 
    something.worked = false; 
    something.err = ex.Message; 
    return something; 
} 
finally { 
    stuff.close(); 
}

Źródło

2011-08-26 ChuckNeuros

@ Dlev - Z wyjątkiem pierwszego nie jest prawidłowym C#, więc nie można tego zrobić. Więc jak to może być lepsze? To pytanie powinno zostać ponownie zadane, gdzie każdy kod jest rzeczywiście prawidłowym kodem, w przeciwnym razie jest bezsensowny. –

@Ramhound Oops, chodzi mi o to, że ten pierwszy nie jest legalny C#. Ta ostatnia jest rzeczywiście poprawna składniowo. – dlev

nie może return z finally Ty. otrzymasz błąd kompilatora:

Control cannot leave the body of a finally clause

Jeśli klasa cel realizuje IDisposable to bym dalej:

using (stuff s = new stuff()) 
{ 
    return stuff; 
}

lub

using (stuff s = new stuff()) 
{ 
    try 
    { 
     // do stuff 
     return stuff; 
    } 
    catch (Exception ex) 
    { 
     // do logging or another stuff 
     return something; 
    } 
}

wezwie Dispose() dla ciebie jeśli wola być wymagane/możliwe.

Źródło

2011-08-26 15:51:40 abatishchev

Doh! Spróbuj skompilować zanim zapytasz następnym razem, Self! To ma sens, że kontrola nie może opuścić w końcu, ponieważ w końcu jest tak wyjątkowa w wymagającej uwagi. – ChuckNeuros

@ user540903: Tak, powinieneś go skompilować. Ale nie bój się zbyt mocno; istnieją języki, w których zwrot z wreszcie jest legalny, a te języki mają w rezultacie jakąś dość dziwną semantykę sterowania przepływem. Jest to uzasadnione pytanie w ogóle, po prostu nie dla C#. –

@Eric I'm pretty Java jest jednym z tych języków. Z tego co pamiętam, ostatnie 'return' nadpisuje poprzednie, więc' try {throw new BlahException(); } catch {return 1; } finally {return 2; } 'faktycznie zwraca' 2' do wywołującego. – dlev

Osobiście chciałbym zrobić i nie użyłby


try { 
    stuff that changes something... 
} 
catch (System.Exception ex) { 
    something.worked = false; 
    something.err = ex.Message; 
} 
finally { 
    stuff.close();  
} 
return something;

również w rachunku finally sprawdzić, że trzeba zamknąć/wyrzucać przedmiotów, gdyż może nigdy nie zostały otwarte/set gdyby zawiodły.

patrz także tutaj Is it bad practice to return from within a try catch finally block?

Źródło

2011-08-26 15:52:33

Zgadzam się z tym, ponieważ abatishchev mówi, że nie możesz wrócić w końcu, nie sądzę, że powinieneś wrócić w haczyku. Jeśli próbujesz złapać i nie powracasz, chcesz, aby powrócił w każdy sposób, a jeśli powrócisz, to i tak nigdy nie wróci. Tak czy inaczej potrzebujesz tylko 1 zwrotnego oświadczenia, a nie 2 –

powrót z próby/catch/finally nie jest uważany za "programowanie strukturalne". Zgadzam się z Timem i Benem. –

Nie ma ryzyka w drugim podejściu. Ale pozwala zwracać różne wartości w przypadku wyjątków.

Źródło

2011-08-26 15:53:06 Stephan

Tak więc zwraca zmienną i ustawia ją na różne wartości w blokach try i catch, ale tylko mając 1 powrót poza całym blokiem try/catach. –

zwracanie wartości zmiennej umożliwiłoby również zwracanie różnych wartości w przypadku wyjątków. –

Powrót w try & catch a zwrot w końcu?

Odpowiedz

Powiązane problemy