try - catch - finally i ich zasięg

Kilka lat już pracuję jako dev, ale niedawno trafiłem na ciekawy komentarz do pull requesta, że mój try obejmuje całe ciało funkcji, zamiast poszczególne wrażliwe jego fragmenty (odwołanie do serwisu, inne rzeczy).
Teraz sporo czasu zastanawiam się, czy jest w ogóle jakiś kanon lub wytyczne? Jakie są wasze preferencje?
Z poprzedniej pracy wyniosłem nawyk implementowanie try - catch w każdej publicznej metodzie z jakimś tam handlowaniem exceptionów lub ich wrapowaniem.
Szczególnie, jeśli chodzi o jakieś rozwiązania serwisowe.
ktoś mi powiedział, że robię tak dlatego, bo nie chce mi się pisać testów jednostkowych ¯\(ツ)/¯
albo taki przypadek z foreachem.
try - catch wokół , czy wewnątrz niego? A może da się jakoś ocenić, w którym momencie, jakie podejście wybrać?
Szczególnie w projektach typu legacy.

No i bądź tu mądry.

Dobre praktyki programowania faktycznie wspominają o tym żeby zasięg bloku try catch był jak najmniejszy oraz żeby łapane wyjątki były jak najbardziej specyficzne.
Chodzi o to żeby przez przypadek nie złapać wyjątków których się nie spodziewamy, na przykład:

try {
   File f = openFile();
   Socket s = openSocket();
   foo(); 
} catch (Exception e) {
  // To z pliku czy z socket'a czy może z foo() ????
}

Z drugiej strony częsty błąd jaki widzę w kodzie to wzorzec zaloguj i rzuć:

catch (JebuduException e) {
  error(e, "cannot xxx");
  throw e;
}

To jest bez sensu, potem masz w logach 5 razy ten sam wyjątek.

To co warto zrobić to opakować (jeżeli ma to sens) dodając odpowiedni kontekst (najczęściej w postaci lepszego opisu co się stało):

catch (JebuduException e) {
   throw new BusinessException("Cannot generate PDF document for invoice: " + invoiceId, e);
} 

Jeżeli chodzi o typowe aplikacje webowo-biznesowe, zazwyczaj robi się jeden globalny exception handler za pomocą filtra lub innego mechanizmu AOP. Nie spotkałem się zbyt często z łapaniem wyjątków w kodzie serwisów (jedyny przypadek jaki pamiętam to było wczytanie pliku Excela gdzie wyjątek był chwytany po to żeby wypisać użytkownikowi odpowiedni błąd).

na szczęście o re-throw exceptiona pluje się sam resharper lub może nawet sam VS.

Opakowywanie Exceptionów, to to co robię, więc z tym nie mam problemów.
ale też spotkałem się z takim podejściem:

try {
   File f = openFile();
   Socket s = openSocket();
   foo(); 
} catch (OpenFileException e) {
     HandleFileOpeningError();
} catch (SocketException e) {
     RetryOperationWtf();
} catch (Exception e) {
     throw new UnhandledException(e);
}

czy to przychwytywanie błędu z when (e.Message.Contains("I need more lemon pledge"))
Jakkolwiek

Ja kiedyś wyczytałem, że nagminne stosowanie bloków try catch to jest połykanie wyjątków i powinno być stosowane głównie w IO, gdzie nie do końca da się przewidzieć dostępność i format zasobu.

O ich zasięgach sobie nic nie przypominam, ale tak na chłopski rozum to się zgodzę z @0xmarcin, że chyba jednak lepiej by były jak najmniejsze i wewnątrz pętli. Dla przykładu, odczyt z csv, jedna źle sformatowana linia pliku może połknąć odczyt całego pliku, jeśli try catch obejmuje całą pętlę.

Też wujek Bob w Czystym kodzie wspomina o tym, żeby try się zaczynało na początku metody / funkcji.

@bakunet:

Dla przykładu, odczyt z csv, jedna źle sformatowana linia pliku może połknąć odczyt całego pliku, jeśli try catch obejmuje całą pętlę.

no to chyba jest to zachowanie pożądane, chcesz przetwarzać niespójne dane?

Według mnie blok try powinien obejmować tylko ten fragment kodu, który może wywołać wyjątek.
https://docs.microsoft.com/pl-pl/dotnet/csharp/programming-guide/exceptions/creating-and-throwing-exceptions

leggo napisał(a):

Z poprzedniej pracy wyniosłem nawyk implementowanie try - catch w każdej publicznej metodzie z jakimś tam handlowaniem exceptionów lub ich wrapowaniem.

I nie nudzi Cię to? Przecież tych try-catch musisz wtedy napisać bardzo dużo.