Jak używać try catch do obsługi wyjątków jest najlepszą praktyką

Najlepszą praktyką jest to, że obsługa wyjątków nigdy nie powinna ukrywać problemów. Oznacza to, że try-catch bloki powinny być niezwykle rzadkie.

Istnieją 3 okoliczności, w których użycie try-catch ma sens.

1. Zawsze radź sobie ze znanymi wyjątkami tak nisko, jak tylko możesz. Jeśli jednak spodziewasz się wyjątku, zwykle lepiej jest najpierw przetestować go. Na przykład wyjątki parsowania, formatowania i arytmetyki są prawie zawsze lepiej obsługiwane przez logika sprawdza najpierw, a nie konkretne try-catch.

2. Jeśli musisz zrobić coś na wyjątku (na przykład logowanie lub cofnięcie transakcji), to ponownie wyrzuć wyjątek.

3. Zawsze radź sobie z wyjątkami unknown jak najwyżej - tylko Kod, który powinien zużywać wyjątek, a nie ponownie go wyrzucać, powinien być interfejsem użytkownika lub publicznym API.

Załóżmy, że łączysz się ze zdalnym API, tutaj wiesz, że możesz się spodziewać niektóre błędy (i mają rzeczy do w tych okolicznościach), więc jest to przypadek 1:

try 
{
    remoteApi.Connect()
}
catch(ApiConnectionSecurityException ex) 
{
    // User's security details have expired
    return false;
}

return true;

Zauważ, że żadne inne wyjątki nie są wyłapywane, ponieważ nie są oczekiwane.

Teraz Załóżmy, że próbujesz zapisać coś do bazy danych. Musimy go cofnąć, jeśli się nie powiedzie, więc mamy przypadek 2:

try
{
    DBConnection.Save();
}
catch
{
    // Roll back the DB changes so they aren't corrupted on ANY exception
    DBConnection.Rollback();

    // Re-throw the exception, it's critical that the user knows that it failed to save
    throw;
}

Zauważ, że ponownie wyrzucamy wyjątek - kod wyżej musi wiedzieć, że coś się nie udało.

Wreszcie mamy UI - tutaj nie chcemy mieć zupełnie nieobsługiwane wyjątki, ale nie chcemy też ich ukrywać. Oto przykład przypadku 3:

try
{
    // Do something
}
catch(Exception ex) 
{
    // Log exception for developers
    WriteException2LogFile(ex);

    // Display message to users
    DisplayWarningBox("An error has occurred, please contact support!");
}

Jednak większość frameworków API lub UI ma ogólne sposoby wykonania przypadku 3. Na przykład ASP.Net ma żółty ekran błędu, który zrzeka się szczegółów wyjątku, ale można go zastąpić bardziej ogólnym Komunikatem w środowisku produkcyjnym. Podążanie za nimi jest najlepszą praktyką, ponieważ oszczędza dużo kodu, ale także dlatego, że rejestrowanie błędów i wyświetlanie powinno być config decyzje, a nie utrudnienia.

To wszystko oznacza, że case 1 (znane wyjątki) i case 3 (Jednorazowa obsługa interfejsu użytkownika) mają lepsze wzorce (unikaj oczekiwanego błędu lub błędu ręcznego).

Nawet przypadek 2 może być zastąpiony przez lepsze wzorce, na przykład zakresy transakcji (using bloki, które wycofują każdą transakcję, która nie została popełniona podczas bloku) utrudniają programistom błędne stosowanie wzorca najlepszych praktyk.

Na przykład Załóżmy, że masz dużą skalę ASP.Net podanie. Rejestrowanie błędów może odbywać się za pomocą ELMAH , wyświetlanie błędów może być informacyjnym YSoD lokalnie i ładnym zlokalizowanym Komunikatem w produkcji. Połączenia z bazą danych mogą odbywać się za pomocą zakresów transakcji i bloków {[6] }. Nie potrzebujesz ani jednego bloku try-catch.

TL;DR: najlepszą praktyką jest, aby w ogóle nie używać try-catch bloków.

Wyjątkiem jest błąd blokowania .

Po pierwsze, najlepszą praktyką powinno być nie wyrzucaj wyjątków dla jakiegokolwiek błędu, chyba że jest to błąd blokujący .

Jeśli błąd to blokowanie , wyrzuć wyjątek. Gdy wyjątek jest już wyrzucony, nie ma potrzeby go ukrywać, ponieważ jest wyjątkowy; poinformuj o tym użytkownika(powinieneś sformatować cały wyjątek na coś użytecznego dla użytkownika w interfejsie).

Na przykład, jeśli wiesz, że niektóre dane integer mogą mieć nieprawidłowy format, użyj int.TryParse zamiast int.Parse. Jest wiele przypadków, w których możesz to zrobić zamiast po prostu mówić "jeśli się nie powiedzie, po prostu rzuć wyjątek".

Rzucanie wyjątków jest drogie.

Jeśli, mimo wszystko, wyjątek jest wyrzucony, zamiast pisać wyjątek do dziennika po jego wyrzuceniu, jedną z najlepszych praktyk jest złapanie go w First-chance exception handler . Na przykład:

• ASP.NET: Global.ASAX Application_Error
• Inne: AppDomain.Zdarzenie FirstChanceException .

Moje stanowisko jest takie, że lokalne próby / połowy lepiej nadają się do obsługi specjalnych przypadków, w których można przetłumaczyć wyjątek do innego, lub gdy chcesz go "wyciszyć" dla bardzo, bardzo, bardzo, bardzo specjalnego przypadku(błąd biblioteki rzucający niezwiązany wyjątek, który musisz wyciszyć, aby obejść cały błąd).

Do reszty przypadków:

Staraj się unikać WYJĄTKÓW.
• jeśli nie jest to możliwe: obsługa wyjątków pierwszej szansy.
• lub użyć aspektu PostSharp (AOP).

Odpowiadasz użytkownikowi thewhiteambit..

Wyjątki nie są fatalne-błędy, są wyjątkami! Czasami oni nie są nawet błędy, ale uznać je za fatalne-błędy jest całkowicie fałszywe zrozumienie, czym są wyjątki.

Po pierwsze, jak wyjątek nie może być nawet błędem?

• Brak połączenia z bazą danych = > wyjątek.
• Nieprawidłowy format łańcucha do przetworzenia do pewnego typu = > wyjątek
• próbuje parsować JSON I while input nie jest w rzeczywistości JSON => exception
• Argument null while object was expected = > exception
• jakaś Biblioteka ma błąd = > wyrzuca nieoczekiwany wyjątek
• jest połączenie z gniazdem i zostaje odłączone. Następnie spróbuj wysłać wiadomość = > wyjątek
• ...

Możemy wymienić 1K przypadków, gdy wyjątek jest wyrzucany, a przecież każdy z możliwych przypadków będzie błędem .

Wyjątek jest błędem, ponieważ na koniec dnia jest obiekt, który zbiera informacje diagnostyczne -- ma wiadomość i dzieje się, gdy coś pójdzie nie tak.

Również, proponuję wszyscy do sprawdzenia paradygmatu Fail-fast opublikowanego przez Martina Fowlera (a napisanego przez Jima Shore ' A) . W ten sposób zawsze rozumiałem, jak radzić sobie z wyjątkami, jeszcze zanim jakiś czas temu dotarłem do tego dokumentu.

[...] uznać je za fatalne-błędy to całkowicie fałszywe zrozumienie czym są wyjątki.

Zazwyczaj wyjątki wycinają jakiś przepływ operacji i są obsługiwane, aby przekształcić je w zrozumiałe dla człowieka błędy. Wydaje się więc, że wyjątek jest w rzeczywistości lepszym paradygmatem do obsługi przypadków błędów i pracy nad nimi, aby uniknąć kompletnej awarii aplikacji/usługi i powiadomić użytkownika / konsumenta, że coś poszło nie tak.

Więcej odpowiedzi na temat @ thewhiteambit

Na przykład w przypadku braku połączenia z bazą danych program może wyjątkowo kontynuować zapis do pliku lokalnego i wysłać zmiany w bazie danych po jej ponownym udostępnieniu. Twój nieprawidłowy Odlewanie strun na liczbę może spróbuj ponownie przeanalizować z language-local interpretation on Exception, like as you try default Język angielski do parsowania ("1,5") nie powiedzie się i spróbujesz z niemieckim znowu interpretacja, która jest całkowicie w porządku, ponieważ używamy przecinka zamiast wskazywać jako separator. Widzisz te wyjątki nie mogą nawet blokują, potrzebują tylko obsługi wyjątków.

1. Jeśli Twoja aplikacja może działać w trybie offline bez przechowywania danych w bazie danych, nie powinieneś używać wyjątki , ponieważ implementacja przepływu sterowania za pomocą {[3] } jest uważana za anty-wzorzec. Praca w trybie Offline jest możliwym przypadkiem użycia, więc implementujesz przepływ kontroli, aby sprawdzić, czy baza danych jest dostępna, czy Nie, Nie czekasz, aż nie będzie dostępna.

2. parsowanie jest również przypadkiem oczekiwanym (nie przypadkiem wyjątkowym). Jeśli tego oczekujesz, nie używasz WYJĄTKÓW do sterowania przepływem!. Dostajesz jakieś metadane od użytkownika, aby wiedzieć, co jego / jej kultura jest i używasz do tego formaterów! . NET obsługuje to i inne środowiska, a wyjątek, ponieważ formatowanie liczb musi być unikane, jeśli oczekujesz specyficznego dla kultury użycia Twojej aplikacji / usługi.

Nieobsługiwany wyjątek zwykle staje się błędem, ale wyjątki same w sobie nie są codeproject.com/Articles/15921/Not-All-Exceptions-Are-Errors

Ten artykuł to tylko opinia lub punkt widzenia autora.

Skoro Wikipedia może być tylko opinią autora (ów) artykułów, to nie powiedziałbym, że to dogmat, ale sprawdź co kodowanie przez wyjątek artykuł mówi gdzieś w jakimś akapicie:

[...] Używanie tych wyjątków do obsługi określonych błędów, które powstają w Kontynuuj program nazywa się kodowaniem przez wyjątek. ten anty-wzorzec może szybko obniżyć wydajność i łatwość konserwacji oprogramowania.

Jest też napisane gdzieś:

Niepoprawne użycie wyjątku

Często kodowanie przez wyjątek może prowadzić do dalszych problemów w oprogramowaniu z nieprawidłowym użyciem WYJĄTKÓW. Oprócz używania WYJĄTKÓW obsługa unikalnego problemu, nieprawidłowe użycie WYJĄTKÓW zabiera to następnie wykonując Kod nawet po wywołaniu wyjątku. To słaba metoda programowania przypomina metodę goto w wielu programach języków, ale występuje tylko po problemie w oprogramowaniu jest wykryto.

• Twoja baza danych może zostać wyłączona...
• niektóre pliki można zablokować...
• niektóre formatowanie może nie być obsługiwane...
• niektóre walidacje domen mogą się nie udać...
• Twoja aplikacja powinna działać w trybie offline...
• niezależnie od przypadku użycia ...

...nie będziesz używać WYJĄTKÓW do tego . Ty by wspierać te przypadki użycia przy użyciu regularnego przepływu sterowania.

I jeśli jakiś nieoczekiwany przypadek użycia nie zostanie zakryty, Twój kod szybko zawiedzie, Ponieważ spowoduje wyrzucenie wyjątku . Racja, ponieważ wyjątek to wyjątkowy przypadek .

Z drugiej strony, i wreszcie, czasami pokrywasz wyjątkowe przypadki rzucając oczekiwane wyjątki , ale nie rzucasz ich, aby zaimplementować przepływ kontroli. Robisz to, ponieważ chcesz powiadomić górne warstwy że nie obsługujesz jakiegoś przypadku użycia lub Twój kod nie działa z podanymi argumentami lub danymi/właściwościami środowiska.

Jedynym momentem, kiedy powinieneś martwić swoich użytkowników o coś, co stało się w kodzie, jest to, czy jest coś, co mogą lub muszą zrobić, aby uniknąć problemu. Jeśli mogą zmienić dane w formularzu, nacisnąć przycisk lub zmienić ustawienia aplikacji, aby uniknąć problemu, powiadom ich o tym. Ale ostrzeżenia lub błędy, których Użytkownik nie ma możliwości uniknąć po prostu sprawia, że tracą zaufanie do produktu.

Wyjątki i logi są dla Ciebie, dewelopera, Nie użytkownika końcowego. Zrozumienie właściwe postępowanie, gdy złapiesz każdy wyjątek, jest o wiele lepsze niż stosowanie złotej reguły lub poleganie na siatce bezpieczeństwa dla całej aplikacji.

Bezmyślne kodowanie to jedyny rodzaj błędnego kodowania. Fakt, że czujesz, że jest coś lepszego, co można zrobić w takich sytuacjach, pokazuje, że zainwestowałeś w dobre kodowanie, ale unikaj prób stemplowania jakiejś ogólnej zasady w tych sytuacjach i zrozum powód, dla którego warto rzucić coś na pierwsze miejsce i co możesz zrobić, aby odzyskać od tego.

Wiem, że to stare pytanie, ale nikt tutaj nie wspomniał o artykule MSDN, a to dokument, który mi to wyjaśnił, MSDN ma Bardzo dobry dokument na ten temat, powinieneś złapać wyjątki, gdy spełnione są następujące warunki:

• Masz dobre zrozumienie, dlaczego wyjątek może zostać wyrzucony, i możesz zaimplementować określone odzyskiwanie, takie jak monitowanie użytkownika o wprowadzenie nowej nazwy pliku podczas przechwytywania FileNotFoundException obiekt.

• Możesz utworzyć i rzucić nowy, bardziej szczegółowy wyjątek.

int GetInt(int[] array, int index)
{
    try
    {
        return array[index];
    }
    catch(System.IndexOutOfRangeException e)
    {
        throw new System.ArgumentOutOfRangeException(
            "Parameter index is out of range.");
    }
}

• chcesz częściowo obsłużyć wyjątek przed przekazaniem go do dodatkowej obsługi. W poniższym przykładzie blok catch jest używany do dodania wpisu do dziennika błędów przed ponownym wyrzuceniem wyjątku.

    try
{
    // Try to access a resource.
}
catch (System.UnauthorizedAccessException e)
{
    // Call a custom error logging procedure.
    LogError(e);
    // Re-throw the error.
    throw;     
}

Sugerowałbym przeczytanie całej sekcji " wyjątki i obsługa wyjątków ", a także najlepsze praktyki dla Wyjątki .

Lepszym podejściem jest drugie podejście (w którym określa się Typ wyjątku). Zaletą tego jest to, że wiesz, że tego typu wyjątki mogą wystąpić w Twoim kodzie. Obsługujesz ten typ wyjątku i możesz wznowić. Jeśli pojawił się jakiś inny wyjątek, oznacza to, że coś jest nie tak, co pomoże Ci znaleźć błędy w kodzie. Aplikacja w końcu ulegnie awarii, ale dowiesz się, że jest coś, co przegapiłeś (błąd), co należy naprawić.

Drugie podejście jest dobre.

Jeśli nie chcesz pokazywać błędu i mylić użytkownika aplikacji pokazując wyjątek runtime(tzn. błąd), który nie jest z nim związany, to po prostu zaloguj błąd i zespół techniczny może znaleźć problem i go rozwiązać.

try
{
  //do some work
}
catch(Exception exception)
{
   WriteException2LogFile(exception);//it will write the or log the error in a text file
}

Zalecam drugie podejście do całej aplikacji.

Zostawić puste blok catch jest gorszą rzeczą do zrobienia. Jeśli wystąpi błąd, najlepszym sposobem na jego usunięcie jest:

1. Zaloguj go do pliku \ bazy danych itp..
2. spróbuj naprawić to w locie (może spróbuj alternatywnego sposobu wykonania tej operacji)
3. Jeśli nie możemy tego naprawić, Powiadom użytkownika o błędzie i oczywiście przerwij operację

Dla mnie obsługa wyjątków może być postrzegana jako reguła biznesowa. Oczywiście pierwsze podejście jest niedopuszczalne. Drugi jest lepszy i może być w 100% poprawny, Jeśli kontekst tak mówi. Teraz, na przykład, opracowujesz dodatek programu Outlook. Jeśli dodasz nieobsługiwany wyjątek, użytkownik programu outlook może teraz o tym wiedzieć, ponieważ program outlook nie zniszczy się z powodu awarii jednej wtyczki. I trudno ci zrozumieć, co poszło nie tak. Dlatego drugie podejście w tym przypadku, dla mnie jest to poprawne. Oprócz rejestrowania wyjątku możesz zdecydować się na wyświetlenie komunikatu o błędzie użytkownikowi - uważam to za regułę biznesową.

Najlepszą praktyką jest rzucanie wyjątku, gdy wystąpi błąd. Ponieważ wystąpił błąd i nie powinien być ukryty.

Ale w prawdziwym życiu można mieć kilka sytuacji, kiedy chcesz to ukryć

1. polegasz na komponencie strony trzeciej i chcesz kontynuować program w przypadku błędu.
2. masz sprawę biznesową, którą musisz kontynuować w przypadku błędu

Powinieneś rozważyć te wytyczne projektowe dla WYJĄTKÓW

• Exception Throwing
• Używanie Standardowych Typów Wyjątków
• wyjątki i wydajność

Https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/exceptions

catch bez żadnych argumentów jest po prostu jedzeniem wyjątkiem i jest bezużyteczny. Co jeśli wystąpi błąd krytyczny? Nie ma sposobu, aby dowiedzieć się, co się stało, jeśli użyjesz catch bez kłótni.

Instrukcja catch powinna wyłapywać więcejkonkretnych wyjątków, takich jak FileNotFoundException, a następnie na samym końcu powinieneś wyłapać Exception, które wyłapywałyby każdy inny wyjątek i zapisywałyby je.

Czasami trzeba traktować wyjątki, które nic nie mówią użytkownikom.

My way is:

• aby wyłapać nieprzewidziane wyjątki na poziomie aplikacji (tj. w skali globalnej.asax) dla krytycznych WYJĄTKÓW (aplikacja nie może być użyteczna). Tych eksepcji nie łapię na miejscu. Po prostu zaloguj je na poziomie aplikacji i pozwól systemowi wykonać swoje zadanie.
• Złap "na miejscu" i pokaż użytkownikowi kilka przydatnych informacji (wprowadzony niewłaściwy numer, nie można przetworzyć).
• Złap na miejscu i nie rób nic na marginesie problemy takie jak "sprawdzę informacje o aktualizacji w tle, ale usługa nie działa".

To zdecydowanie nie musi być najlepsza praktyka. ;-)

Z wyjątkami staram się:

Po pierwsze, wyłapuję specjalne typy WYJĄTKÓW, takie jak dzielenie przez zero, operacje IO itd. i piszę kod zgodnie z tym. Na przykład, dzielenie przez zero, w zależności od proweniencji wartości mogę ostrzec użytkownika (przykład prosty kalkulator w tym, że w środku obliczenia (nie argumenty) przybywa w podziale przez zero) lub cicho traktować ten wyjątek, rejestrując go i kontynuować przetwarzanie.

Potem staram się złapać Pozostałe wyjątki i zaloguj je. Jeśli to możliwe, pozwól na wykonanie kodu, w przeciwnym razie Powiadom użytkownika, że wystąpił błąd i poproś go o przesłanie raportu o błędzie.

W kodzie, coś takiego:

try{
    //Some code here
}
catch(DivideByZeroException dz){
    AlerUserDivideByZerohappened();
}
catch(Exception e){
    treatGeneralException(e);
}
finally{
    //if a IO operation here i close the hanging handlers for example
}