Najlepsze praktyki zarządzania wyjątkami w Javie lub C # [zamknięty]

To zależy od aplikacji i sytuacji. Jeśli tworzysz komponent biblioteki, powinieneś dodać pęcherzyki, chociaż powinny one być zawinięte tak, aby były kontekstowe z Twoim komponentem. Na przykład, jeśli budujesz bazę danych Xml i powiedzmy, że używasz systemu plików do przechowywania danych, a używasz uprawnień systemu plików do zabezpieczania danych. Nie chciałbyś, aby wyjątek FileIOAccessDenied był bańką, ponieważ przecieka to z Twojej implementacji. Zamiast tego zawinąłbyś exception and throw an accessdenied error. Jest to szczególnie ważne, jeśli rozpowszechniasz komponent stronom trzecim.

Jeśli można przełknąć wyjątki. To zależy od Twojego systemu. Jeśli aplikacja może obsłużyć przypadki awarii i nie ma korzyści z powiadamiania Użytkownika, dlaczego nie powiodło się, to śmiało, chociaż Gorąco polecam, aby twój dziennik awarii. Zawsze uważałem, że frustrating jest wywoływany, aby pomóc rozwiązać problem i znaleźć, że połykają wyjątek (lub zastąpienie go i rzucenie nowego bez ustawiania wewnętrznego wyjątku).

Ogólnie stosuję następujące zasady:

1. w moich komponentach i bibliotekach wyłapuję wyjątek tylko wtedy, gdy mam zamiar go obsłużyć lub zrobić coś na jego podstawie. Lub jeśli chcę podać dodatkowe informacje kontekstowe w wyjątku.
2. używam ogólnego połowu próbnego w punkcie wejścia do aplikacji, lub na najwyższym możliwym poziomie. Jeśli pojawi się wyjątek, po prostu go loguję i pozwalam porażka. Najlepiej, żeby wyjątki nigdy tu nie dotarły.

Uznaję następujący kod za zapach:

try
{
    //do something
}
catch(Exception)
{
   throw;
}

Taki kod nie ma sensu i nie powinien być uwzględniany.

Chciałbym polecić inne dobre źródło na ten temat. Jest to wywiad z twórcami C# i Javy, odpowiednio Andersem Hejlsbergiem i Jamesem Goslingiem, na temat sprawdzonego wyjątku Javy.

Awarie i wyjątki

Są też świetne zasoby na dole strony.

Zgadzam się z Andersem Hejlsbergiem i Tobą, że większość rozmówców dba tylko o to, czy operacja się powiedzie, czy nie.

Bill Venners: Ty wspomniane problem skalowalności i wersjonowania w odniesieniu do sprawdzonych WYJĄTKÓW. Czy mógłbyś wyjaśnić, co masz na myśli przez te dwa problemy?

Anders Hejlsberg : zacznijmy od wersjonowanie, ponieważ problemy są dość łatwo tam dostrzec. Powiedzmy, że Utwórz metodę foo, która ją deklaruje rzuca wyjątki A, B i C. W wersja druga foo, chcę dodać kilka funkcji, a teraz foo może throw exception D. Jest to łamanie zmień dla mnie dodaj D do rzutów klauzula tej metody, ponieważ istniejący rozmówca tej metody będzie prawie na pewno nie poradzić sobie z tym wyjątek.

Dodawanie nowego wyjątku do rzutów klauzula w nowej wersji łamie klienta kod. To jak dodanie metody do interfejs. Po opublikowaniu interfejs, jest dla wszystkich praktyczny cele niezmienne, ponieważ wszelkie realizacja może mieć metody, które chcesz dodać w następna wersja. Więc musisz stworzyć nowy zamiast tego interfejs. Podobnie z wyjątkami, albo aby utworzyć zupełnie nową metodę o nazwie foo2 który wyrzuca więcej wyjątków lub trzeba by złapać wyjątek D w nowy foo i przekształcić D w A, B lub C.

Bill Venners : Ale czy ty nie łamiesz ich kod w takim razie, nawet w języku bez sprawdzania wyjątki? Jeśli nowa wersja foo rzuci nowy wyjątek, który klienci powinni pomyśleć o obsługa, czy ich kod nie jest łamany tylko przez fakt, że nie spodziewali się, że wyjątek, kiedy napisali kod?

Anders Hejlsberg : nie, bo w wielu ludzi to nie obchodzi. Są Nie będę się nimi zajmował. wyjątki. Jest dolny poziom obsługa wyjątków wokół wiadomości pętla. Ten handler po prostu będzie wywołanie okna dialogowego, które mówi, co poszło źle i kontynuuj. Programiści Chroń swój kod pisząc spróbuj w końcu jest wszędzie, więc wrócą się poprawnie, jeśli wystąpi wyjątek, ale nie są zainteresowani obsługa wyjątków.

Klauzula rzutów, przynajmniej sposób jest zaimplementowany w Javie, nie koniecznie zmusić cię do obsługi wyjątki, ale jeśli nie obsłużysz ich, zmusza do uznania dokładnie jakie wyjątki mogą przejść przez. Wymaga albo złowić zadeklarowane wyjątki lub umieścić je we własnych rzutach. Na praca wokół tego wymogu ludzie robią śmieszne rzeczy. Na przykład, oni udekoruj każdą metodą, " rzuca Wyjątek."To po prostu całkowicie pokonuje funkcję, a Ty właśnie dokonałeś programista pisze wiecej gobbledy gunk. To nikomu nie pomoże.

EDIT: Dodano więcej szczegółów na temat converstaion

Zaznaczone wyjątki są ogólnie kontrowersyjną kwestią, a w szczególności w Javie(później postaram się znaleźć kilka przykładów dla tych, którzy są za i przeciw).

Jako zasady, obsługa wyjątków powinna być czymś wokół tych wytycznych, w żadnej szczególnej kolejności:

• ze względu na łatwość utrzymania, Zawsze zapisuj wyjątki, aby gdy zaczniesz widzieć błędy, dziennik pomoże Ci wskazać miejsce, w którym prawdopodobnie zaczął się twój błąd. Never leave printStackTrace() or są szanse, że jeden z Twoich użytkowników w końcu dostanie jeden z tych śladów stosu i będzie miał dokładnie zerową wiedzę , co z tym zrobić.
• Złap wyjątki, z którymi możesz sobie poradzić, i tylko te, i zajmij się nimi , nie wyrzucaj ich po prostu na stosie.
• zawsze łap określoną klasę wyjątków i generalnie nigdy nie powinieneś łap typu Exception, jest bardzo prawdopodobne, że przełkniesz Inne ważne wyjątki.
• Never (ever) catch Errors!!, czyli: nigdy nie łap Throwable s ponieważ Error s są podklasami tych ostatnich. Error S to problemy, z którymi prawdopodobnie nigdy nie będziesz w stanie sobie poradzić (np. OutOfMemory, lub inne problemy z JVM)

Jeśli chodzi o twój konkretny przypadek, upewnij się, że każdy klient wywołujący Twoją metodę otrzyma odpowiednią wartość zwracaną. Jeśli coś się nie powiedzie, metoda boolean-returning może zwrócić false, ale upewnij się, że miejsca wywołane przez tę metodę są w stanie to obsłużyć.

Powinieneś łapać tylko wyjątki, z którymi możesz sobie poradzić. Na przykład, jeśli masz do czynienia z odczytem przez Sieć i czasem połączenia, a otrzymasz wyjątek, możesz spróbować ponownie. Jeśli jednak czytasz przez Sieć i otrzymujesz wyjątek IndexOutOfBounds, naprawdę nie możesz sobie z tym poradzić, ponieważ nie wiesz (dobrze, w tym przypadku nie będziesz), co go spowodowało. Jeśli chcesz zwrócić false, -1 lub null, upewnij się, że dotyczy to konkretnych WYJĄTKÓW. Nie chcę biblioteki, której używam zwracanie false w odczycie sieciowym, gdy rzucony wyjątek to sterta nie ma pamięci.

Wyjątkami są błędy, które nie są częścią normalnego wykonywania programu. W zależności od tego, co robi twój program i jego zastosowania (np. edytor tekstu vs monitor serca) będziesz chciał robić różne rzeczy, gdy napotkasz wyjątek. Pracowałem z kodem, który używa WYJĄTKÓW jako części normalnego wykonywania i jest to zdecydowanie zapach kodu.

Ex.

try
{
   sendMessage();

   if(message == success)
   {
       doStuff();
   }
   else if(message == failed)
   {
       throw;
   }
}
catch(Exception)
{
    logAndRecover();
}

Wszystkie powyższe wydaje się rozsądne, a często twoje miejsce pracy może mieć politykę. U nas zdefiniowaliśmy typy WYJĄTKÓW: SystemException (niezaznaczone) i ApplicationException (sprawdzone).

Uzgodniliśmy, że SystemException S są mało prawdopodobne, aby można było je odzyskać i będą obsługiwane raz na górze. Aby zapewnić dalszy kontekst, nasze SystemException S są rozszerzone, aby wskazać miejsce ich wystąpienia, np. RepositoryException, ServiceEception, itd.

ApplicationExceptions może mieć znaczenie biznesowe jak InsufficientFundsException i powinny być obsługiwane przez Klienta kod.

Witohut konkretny przykład, trudno skomentować Twoją implementację, ale nigdy nie użyłbym kodów zwrotnych, są to problemy z konserwacją. Możesz przełknąć wyjątek, ale musisz zdecydować, dlaczego i zawsze rejestrować Zdarzenie i stacktrace. Wreszcie, ponieważ twoja metoda nie ma innego przetwarzania, jest dość zbędna (z wyjątkiem enkapsulacji?), więc doactualStuffOnObject(p_jsonObject); może zwrócić wartość logiczną!

Po pewnym namyśle i spojrzeniu na Twój kod wydaje mi się, że po prostu zmieniasz wyjątek jako boolean. Możesz po prostu pozwolić metodzie przepuścić ten wyjątek (nawet nie musisz go łapać) i poradzić sobie z nim w rozmówcy, ponieważ jest to miejsce, w którym ma to znaczenie. Jeśli wyjątek spowoduje, że wywołujący ponownie spróbuje tej funkcji, to wywołujący powinien przechwytywać wyjątek.

Może się zdarzyć, że napotkany wyjątek nie sprawi wyczuwaj wywołujący (tzn. jest to wyjątek sieciowy), w którym to przypadku powinieneś zawinąć go w wyjątek specyficzny dla domeny.

Jeśli z drugiej strony, wyjątek sygnalizuje nieodwracalny błąd w twoim programie (tzn. ewentualnym rezultatem tego wyjątku będzie zakończenie programu), osobiście chciałbym to wyraźnie zaznaczyć, łapiąc go i rzucając wyjątek runtime.

Jeśli zamierzasz użyć wzorca kodu w swoim przykładzie, nazwij go TryDoSomething i wyłapuj tylko określone wyjątki.

Również rozważ użycie filtra WYJĄTKÓW podczas rejestrowania WYJĄTKÓW do celów diagnostycznych. VB ma wsparcie językowe dla filtrów WYJĄTKÓW. Link do bloga Greggm ma implementację, którą można wykorzystać z C#. Filtry WYJĄTKÓW mają lepsze właściwości debugowania nad catch i rethrow. W szczególności możesz zarejestrować problem w filtruj i pozwól, aby wyjątek nadal się rozprzestrzeniał. Metoda ta umożliwia dołączanie debuggera JIT (Just In Time) do pełnego oryginalnego stosu. Rethrow odcina stos w miejscu, w którym został przetarty.

Przypadki, w których TryXXXX ma sens, są wtedy, gdy owijasz funkcję strony trzeciej, która rzuca w przypadkach, które nie są naprawdę wyjątkowe, lub są proste trudne do przetestowania bez wywołania funkcji. Przykładem może być coś w stylu:

// throws NumberNotHexidecimalException
int ParseHexidecimal(string numberToParse); 

bool TryParseHexidecimal(string numberToParse, out int parsedInt)
{
     try
     {
         parsedInt = ParseHexidecimal(numberToParse);
         return true;
     }
     catch(NumberNotHexidecimalException ex)
     {
         parsedInt = 0;
         return false;
     }
     catch(Exception ex)
     {
         // Implement the error policy for unexpected exceptions:
         // log a callstack, assert if a debugger is attached etc.
         LogRetailAssert(ex);
         // rethrow the exception
         // The downside is that a JIT debugger will have the next
         // line as the place that threw the exception, rather than
         // the original location further down the stack.
         throw;
         // A better practice is to use an exception filter here.
         // see the link to Exception Filter Inject above
         // http://code.msdn.microsoft.com/ExceptionFilterInjct
     }
}

Czy używasz Wzór Jak TryXXX czy nie to raczej kwestia stylu. Kwestia złapania wszystkich wyjątków i przełknięcia ich nie jest kwestią stylu. Upewnij się, że nieoczekiwane wyjątki są dozwolone do propagacji!

Sugeruję pobranie wskazówek z biblioteki standardowej dla języka, którego używasz. Nie mogę mówić za C#, ale spójrzmy na Javę.

Na przykład java.lang.zastanów się.Tablica ma statyczną metodę set:

static void set(Object array, int index, Object value);

Droga C będzie

static int set(Object array, int index, Object value);

... przy czym wartość zwrotu jest wskaźnikiem sukcesu. Ale nie jesteś już w świecie C.

Po zaakceptowaniu WYJĄTKÓW powinieneś zauważyć, że dzięki temu Twój kod staje się prostszy i jaśniejszy, odchodząc od kodu obsługi błędów z twojej podstawowej logiki. Staraj się mieć wiele wyrażeń w jednym bloku try.

Jak zauważyli inni-powinieneś być jak najbardziej konkretny w rodzaju wyjątku, który łapiesz.

Jeśli chcesz wyłapać wyjątek i zwrócić false, powinien to być bardzo konkretny wyjątek. Nie zrobisz tego, złapiesz ich wszystkich i oddasz fałszywe. Jeśli dostanę MyCarIsOnFireException chcę o tym wiedzieć od razu! Reszta wyjątków może mnie nie obchodzić. Więc powinieneś mieć stos obsługi wyjątków, które mówią "whoa whoa coś jest nie tak tutaj" dla niektórych wyjątków (rethrow, lub złapać i rethrow nowy wyjątek, który lepiej wyjaśnia, co się stało) i po prostu zwróć fałszywy dla innych.

Jeśli jest to produkt, który będziesz uruchamiał, powinieneś gdzieś rejestrować te wyjątki, pomoże Ci to dostroić rzeczy w przyszłości.

Edit: co do kwestii zawijania wszystkiego w try/catch, myślę, że odpowiedź brzmi tak. Wyjątki powinny być tak rzadkie w Twoim kodzie, że kod w bloku catch jest wykonywany tak rzadko, że w ogóle nie wpływa na wydajność. Wyjątkiem powinien być stan, w którym zepsuła się maszyna stanowa i nie wiesz, co robić. Przynajmniej rethrow wyjątek, który wyjaśnia, co się działo w tym czasie i ma złapany wyjątek w środku. "Wyjątek w metodzie doSomeStuff ()" nie jest zbyt pomocny dla każdego, kto musi dowiedzieć się, dlaczego zepsuł się, gdy jesteś na wakacjach (lub w nowej pracy).

Moja strategia:

Jeśli oryginalna funkcja zwróciła void zmieniam ją na return bool . Jeśli wystąpił wyjątek/błąd return false, if everything was fine return true.

Jeśli funkcja powinna zwrócić coś wtedy, gdy wystąpił wyjątek/błąd, zwróć null, w przeciwnym razie zwracany element.

Zamiast boolmoże zostać zwrócony łańcuch znaków zawierający opis błędu.

W każdym przypadku przed zwróceniem czegokolwiek Zaloguj błąd.

Kilka doskonałych odpowiedzi tutaj. Chciałbym dodać, że jeśli skończysz z czymś takim jak opublikowałeś, przynajmniej wydrukuj więcej niż ślad stosu. Powiedz, co robiłeś w tym czasie, i Ex.getMessage (), aby dać deweloperowi szansę walki.

Bloki Try / catch tworzą drugi zestaw logiki osadzony nad pierwszym (głównym) zestawem, jako taki są świetnym sposobem na wybijanie nieczytelnego, trudnego do debugowania kodu spaghetti.

Mimo to, użyte rozsądnie działają cuda w czytelności, ale należy przestrzegać dwóch prostych zasad:

• Użyj ich (oszczędnie) na niskim poziomie, aby wychwycić problemy z obsługą biblioteki i przesłać je z powrotem do głównego logicznego przepływu. Większość obsługi błędów, które chcemy, powinna pochodzić z kodu siebie, jako część samych danych. Po co tworzyć specjalne warunki, jeśli zwracane dane nie są specjalne?

• Użyj jednego dużego programu obsługi na wyższym poziomie, aby zarządzać dowolnymi lub wszystkimi dziwnymi warunkami pojawiającymi się w kodzie, które nie są przechwytywane na niskim poziomie. Zrób coś użytecznego z błędami (dzienniki, ponowne uruchomienie, odzyskiwanie, itp.).

Poza tymi dwoma typami obsługi błędów, cała reszta kodu w środku powinna być wolna i wolna od kodu try/catch i błędu obiektów. W ten sposób działa po prostu i zgodnie z oczekiwaniami, bez względu na to, gdzie go używasz lub co z nim robisz.

Paweł.

Mogę się trochę spóźnić z odpowiedzią, ale obsługa błędów jest czymś, co zawsze możemy zmienić i ewoluować w czasie. Jeśli chcesz poczytać coś więcej na ten temat, napisałem post na moim nowym blogu o tym. http://taoofdevelopment.wordpress.com

Szczęśliwe kodowanie.