Typowe błędy w obsłudze wyjątków

Wyjątkiem jest zakłócenie normalnego przepływu wykonywania programu Java (lub dowolnego innego). To naruszenie może wystąpić w wyniku naruszenia dostępu do pamięci, dzielenia przez zero, problemu z inicjalizacją, wykonania niedozwolonej instrukcji lub innego krytycznego błędu. Java jest w stanie bezproblemowo poradzić sobie ze wszystkimi takimi niechcianymi scenariuszami, ale jeśli chodzi o korzystanie z tych funkcji Java przez programistów, może pojawić się kilka problemów. W tym artykule nie będę omawiał, jak działa obsługa wyjątków w Javie. Zakładam, że czytelnik jest już zaznajomiony z hierarchią wyjątków, wyjątkami sprawdzonymi , wyjątkami niesprawdzonymi i wyjątkami środowiska wykonawczego . Tutaj omówimy najczęstsze błędy, których należy unikać.

Interesariusze w wyjątkach

Ilekroć wątek wykonania zostanie przerwany, informacja o tym musi zostać zwrócona do wykonawcy programu. Ten wątek można rozpocząć z ekranu, z zadania wsadowego lub w jakikolwiek inny sposób. Wszystkie te wyzwalacze czekają na jakieś naruszenie przepływu, aby przesłać wiadomość w określonym formacie. Wyzwalacz ekranowy może delikatnie poinformować nas o pewnych problemach technicznych i powinniśmy skontaktować się z pomocą techniczną w celu uzyskania pomocy i porady. Procesy wsadowe lub samodzielne programy Java mogą oczekiwać, że raport o błędach pojawi się w formie dziennika, który będzie całkowicie niezrozumiały dla użytkownika końcowego. Jednak ludzie biznesu muszą otrzymywać wiadomości w języku, który rozumieją. Przerażający wyjątek NullPointerException w umysłach użytkowników jest bardzo irytujący. Czasami błędy te są konsekwencją nieprawidłowego użycia programu, ale czasami są to problemy wymagające korekty. Drugim ważnym interesariuszem jest osoba, która będzie musiała uporać się z problemami wynikającymi z wyjątków. Osoba ta nie może obserwować faktycznego wykonywania programu, gdy wystąpi wyjątek. Będzie się opierać na dwóch rzeczach – po pierwsze, informacjach dostarczonych przez użytkownika, który ma problem, a po drugie, jakimś dzienniku generowanym w przypadku wystąpienia wyjątku. Ponadto osoba, która będzie analizować problem, nie jest tą samą osobą, która napisała program, dlatego twórca programu musi dostarczyć wystarczającą ilość informacji do analizy. Jedynym sposobem komunikacji pomiędzy twórcą programu a jego debugerem jest dziennik. Ponadto czasami ze względów bezpieczeństwa dziennik dziennika może czasami nie zawierać wszystkich rzeczywistych szczegółów wykonania programu, gdy wystąpił wyjątek. Przyjrzyjmy się możliwym błędom w obsłudze wyjątków. Niektóre z nich wyglądają dość głupio, ale są ludzie. którzy nie zwracają na nie uwagi, dopóki błędy te nie doprowadzą do problemów.

Pusty blok wyjątków

Jest to jeden z najbardziej niepożądanych błędów w obsłudze wyjątków. W tym przypadku wyjątek jest po prostu ignorowany. Rozwiązanie zawiera tylko wiersz komentarza umożliwiający pozostawienie wyjątku. try{ }catch(SQLException sqe){ // do nothing } W niektórych rzadkich przypadkach, na przykład w ostatnim bloku, gdy baza danych jest zamykana, mogą zostać zgłoszone wyjątki. W tym przypadku można je zignorować. try{ }catch(SQLException sqe){ ... ... }finally{ try{ conn.close(); }catch(Exception e){ //leave it. } }

Nieprawidłowe uogólnienie komunikatu o wyjątku

Ten punkt jest subiektywny. Po przechwyceniu wyjątku możesz zgłosić go użytkownikowi końcowemu w formie przyjaznej wiadomości. Jest całkiem możliwe, że szczegóły oryginalnej wiadomości zostaną utracone, gdy oryginalne wiadomości zostaną przekształcone w jedną ogólną wiadomość. Wiadomość powinna przekazywać użytkownikowi końcowemu odpowiednią informację, tak aby kontaktując się z zespołem wsparcia wystarczyło zalogować się do odpowiedniego logu i podać informację. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new Exception("File Processing Failed",ioe); } W aplikacji wielowarstwowej każda warstwa wychwytuje wyjątki i zgłasza nowy typ wyjątku. Czasami absolutnie konieczne jest rzucenie wyjątku określonego typu: - Warstwa dostępu do danych -> tworzy wyjątek DataAccessException - Warstwa implementacji biznesowej -> tworzy wyjątek biznesowy - Warstwa usług aplikacji -> tworzy wyjątek ApplicationServiceException Wszystko wydaje się logiczne, prawda? W tym przypadku być może będziemy musieli wybrać pomiędzy ApplicationServiceException i BusinessException, ponieważ oba mogą reprezentować te same informacje. Jedna z tych konwersji wyjątków wydaje się niepotrzebna.

Niszczenie klasy StackTrace

Podczas procesu przekształcania wyjątku w nowy typ specjalny ślad stosu może zniknąć, co sprawia, że ​​śledzenie rzeczywistej przyczyny wyjątku staje się koszmarem. W poniższym kodzie możesz zobaczyć, jak zgłaszany jest nowy wyjątek bez otrzymywania żadnych informacji z pierwotnego wyjątku. try{ File file = new File(""); file.getCanonicalPath(); }catch(IOException ioe){ throw new MyException("Problem in data reading."); }

Zastąpienie powodu wyjątku

Każdy komunikat o wyjątku zawiera informacje o przyczynie wyjątku. Jednak w przypadku utworzenia nowego wyjątku informacje o starym mogą zostać trwale usunięte. Jest to podobne do powyższego przykładu, w którym StackTrace może zostać usunięty z powodu zgłoszenia nowego wyjątku.

Bez wyszukiwania konkretnych wyjątków

Czasami programiści lubią zachować ostrożność podczas obsługi wyjątków. Czasami jest to łatwe. Jednak przechwytywanie wyjątku Java.lang.Exception zamiast konkretnego wyjątku jest niedopuszczalne. try{ File file = new File(""); file.getCanonicalPath(); }catch(Exception exe){ throw new MyException("Problem in data reading."); }

Niepotrzebne łapanie i rzucanie

Przechwytuj wyjątki, jeśli chcesz je przekonwertować na inny typ lub jeśli pomaga to w dodaniu informacji do komunikatu o wyjątku dla użytkownika końcowego lub analityka. W przeciwnym razie po prostu wyrzuć je dalej w sygnaturze metody (używając rzutów), zamiast je łapać.

Łapanie wyjątku RuntimeException

Polecam unikać przechwytywania wyjątku RuntimeException. Zamiast tego lepiej wychwycić określone wyjątki i je leczyć.

Znajdowanie niesprawdzonych wyjątków

Kontrowersyjnym tematem jest to, czy wychwytywać niesprawdzone wyjątki, czy nie. NullPointerException i ArrayIndexOutOfBound mogą być najlepszymi przykładami niesprawdzonych wyjątków. Zamiast przechwytywać te wyjątki, możesz zmienić kod, aby obsłużyć te scenariusze. Na przykład, aby uniknąć wyjątku NullPointerException, aby upewnić się, że wszystkie zmienne zostały zainicjowane, aby uniknąć wyjątków ArrayIndexOutOfBound, aby zdefiniować tablicę o prawidłowej długości itp.

Problemy związane z rejestrowaniem wyjątków

Magazyn pomoże drugiej zainteresowanej osobie, czyli osobie analizującej problem. Czasami programista przesadza z plikami dziennika i logi są tworzone na każdym poziomie aplikacji. Dziennik powinien rejestrować wyjątek na poziomie, na którym wystąpił. Optymalne wydaje się wyświetlenie ostrzeżenia o wystąpieniu wyjątku z propozycją wstrzymania lub kontynuowania wykonywania programu i obowiązkowym zarejestrowaniem wyjątku w logu.

Wyjątek kontroli przepływu

Wyjątkiem jest zakłócenie normalnego przebiegu programu, co oznacza, że ​​należy przerwać ten przepływ i poinformować o tym użytkownika końcowego. Jeśli dodamy wywołanie metody będące wątkiem alternatywnym, doprowadzi to do ogromnych problemów konserwacyjnych. try{ myObject.getValue(); }catch(NullPointerException npe){ alternateMethod(); }

Wszechobecne użycie wyjątku java.lang.Exception

Nie jest również dobrym pomysłem używanie wyjątku Java.lang.Exception wszędzie dla każdego wyjątku. Zamiast tego lepiej jest używać wyjątków specyficznych dla aplikacji lub najbardziej odpowiednich standardowych wyjątków Java. Artykuł oryginalny: Typowe błędy w obsłudze wyjątków Przetłumaczone i nagłośnione przez: Ve4niY