Potrzebujesz wiarygodnego źródła, dla którego nie powinieneś rzucać lub łapać java.lang.Exception

Question

Mam spotkanie standardów kodowania w nieco ponad godzinę i potrzebuję szybkiej odpowiedzi na to.

Powszechną wiedzą wśród doświadczonych programistów Java jest to, że nie rzuca się ani nie przechwytuje wyjątku java.lang.Exception (z rzadkimi wyjątkami - gra słów nie jest przeznaczona). Powodem nie rób tego jest to, że oświadczenie

catch (java.lang.Exception ex) {...} 

również złapać niezaznaczone wyjątkami, w większości przypadków nie jest to, co jest przeznaczone.

Mamy już wiele starszych kodów napisanych przez istniejących członków zespołu, którzy przechwytują podklasę klasy java.lang.Exception, rejestrują błąd i ponownie rzucają podklas jako wyjątek java.lang.Exception.

muszę przekonać ich, że

1. Muszą przestać pisać kod w ten sposób.
2. Istniejący kod, który używa tego anty-wzorzec musi być ustalona

Numer 2 oznacza sporo refaktoringu.

Spowoduje to skrócenie argumentacji na spotkaniu, jeśli mogę wyświetlić artykuł lub wpis na blogu jednego z członków społeczności Java wagi ciężkiej, który to czyni (np. Joshua Bloch, James Gosling). Mój google-fu jeszcze niczego nie odkrył.

Czy ktoś wie o artykule lub blogu szanowanego guru Java, który mówi, że nie powinieneś rzucać lub łapać java.lang.Exception?

Szybkie odpowiedzi są mile widziane.

Dean

Answer 1

Chyba chodzi o to, że jeśli nie wiesz jak obsługiwać konkretny wyjątek to nie powinien go złapać. Powinien rozprzestrzeniać się na wyższy poziom w nadziei, że będzie wiedział, co z tym zrobić. Łapanie wyjątków zbyt wcześnie prowadzi do po cichu połkniętych wyjątków i uniemożliwia im zrobienie z nich czegoś pożytecznego poza logowaniem.

Wyobraź sobie, co by się stało, gdyby konstruktor FileInputStream miał wewnętrznie zarejestrować wyjątek, jeśli próbowałeś otworzyć plik, który nie istnieje, ale nie wskazałeś tego błędu w kodzie. Nie ma problemu, że błąd zostanie zarejestrowany, ale twój kod chciałby przechwycić ten wyjątek i zrobić z nim coś użytecznego (np. Monitując użytkownika o nową nazwę pliku). Gdyby mieli catch (Exception), nie bylibyście w stanie tego zrobić.

Answer 2

Jeśli masz pod ręką efektywną Javę Josh Blocha, wiem, że omawia tutaj obsługę wyjątków. Obecnie nie mam do niego dostępu, więc nie mogę podsumować go ani podać referencji do strony, ale jestem prawie pewny, że ma kilka dobrych argumentów za nieotrzymaniem java.lang.Exception.

Answer 3

Tutaj jest Bruce Eckel's viewpoint on checked exceptions in general, co w większości przypadków jest złym pomysłem. Może to będzie coś, z czego możesz skorzystać.

Answer 4

Nie ma tutaj wspólnej płaszczyzny.Znajdziesz tu dwie grupy:

1. Ci, którzy nienawidzą sprawdzane wyjątki złapie i owinąć je w RuntimeException pewnego rodzaju.

2. Ci, którzy nienawidzą RuntimeException

Pierwsza grupa nienawidzi zagadkę ich kodu z try...catch, zwłaszcza, że ​​w większości przypadków nie można obsłużyć wyjątek, kiedy pierwszy raz to widzę. Pomyśl IOException: Można go rzucić na każdy bajt, który czytasz. Jaki jest kod niskiego poziomu, który można z tym zrobić? Musi go ponownie rzucić, aby ktoś wyższy mógł dodać użyteczny kontekst do błędu (np. Który plik czytałeś).

Druga grupa chce zobaczyć, co może pójść nie tak. RuntimeException skutecznie to ukrywa.

Istnieje prosta poprawka, BTW: Make Exception rozszerzający wyjątek RuntimException. Szalony? Nie całkiem. Jeśli zrobisz to za pomocą JDK 7, otrzymasz dwa błędy kompilacji.

Następnym krokiem będzie sprawdzenie, czy wszystkie kompilatory Java wyliczają wszystkie wyjątki środowiska wykonawczego i wyświetlają je w pozycji throws w pliku klasy. Nadal nie musisz ich łapać, ale teraz wiesz, które z nich mogą się wydarzyć.

Na koniec, rozszerz IDE, aby to wyświetlić. I presto, obie grupy mogłyby być szczęśliwe. Niestety tak się nie stanie.

Answer 5

Oto coś: Java Tip 134: When catching exceptions, don't cast your net too wide (JavaWorld)

Effective Java (Second Edition) przez Joshua Bloch może mieć coś na ten temat w rozdziale 9 (wyjątki), chociaż nie mogłem znaleźć nic na temat szybko nie połowu Exception.

Oto a Q&A from JavaWorld na temat pytania (wskazuje również na Java Tip 134) - wyjaśnia również, dlaczego czasami trzeba złamać zasadę nie łapania Exception lub nawet Throwable.

Answer 6

Zobacz this article z Brian Goetz (kreator współbieżności), który ma swoją własną wiedzę, a także podając Josh Bloch w Effective Java

Answer 7

gdzie złapią podklasę java.lang.Exception zalogować błąd, i ponownie podklasę podklasy jako wyjątek java.lang.Exception. Muszę ich przekonać, że muszą przestać pisać taki kod.

Zgadzam się, że należy zastosować inną taktykę, ale z różnych powodów. Nie ma większego sensu chwytanie wyjątku tylko po to, aby go zarejestrować i ponownie rzucić.

Alternatywą jest: nie przechwytuj wyjątku i pozwól, aby wyższy kod (jak filtr Java EE lub try/catch w metodzie main()) przechwytywał i rejestrował wszystkie nieprzechwycone wyjątki. Wtedy upewnisz się, że każdy wyjątek jest rejestrowany tylko raz i wiesz, że wszystkie nieprzechwycone wyjątki będą rejestrowane.

Aby dodać dodatkowe informacje do wyjątku, należy go przechwycić, zmienić wiadomość i ponownie ją przesłać.Zwykle używam RuntimeException na to:

} catch (Exception originalException) { 
    throw new RuntimeException("user name was " + userName, originalException); 
} 

Answer 8

to jest długi artykuł ale this proponuje Ci:

1. użycie sprawdzane wyjątki, gdy klient oczekuje tego błędu regularnie występować i musi je (ex obsłużyć: Użytkownik dane -entered nie przechodzą walidację)
2. użytku niesprawdzony wyjątki dla niespodziewanych warunkach (np: serwer DB zszedł)

W teorii, # 1 (exp omówione błędy) powinny mieć swój własny typ wyjątku, a jedynym miejscem, które powinno wychwycić # 2 (wyjątek RuntimeException) jest pewien rodzaj obsługi najwyższego poziomu, który przechwytuje wyjątek, rejestruje go i pokazuje użytkownikowi komunikat o błędzie, a nawet tutaj prawdopodobnie powinieneś złapać Throwable, aby upewnić się, że obsługiwane są wszystkie nieprzechwycone wyjątki.

Postępując zgodnie z tymi wskazówkami, nie należy przechwytywać wyjątków, ponieważ nie spełniają one żadnego z powyższych kryteriów (co oznacza, że ​​nie jest to wyjątek RuntimeException i nie jest to wyspecjalizowana podszewka wyjątku wskazująca oczekiwany błąd).

Answer 9

Tutaj jest bardzo insightful article

Podsumowanie:

1. Korzystanie sprawdzone wyjątki dla nielicznych, ale ważnych warunkowych, które odnoszą się do celów kodzie. Kod klienta powinien wiedzieć, jak sobie z nimi radzić.

2. Użyj niezaznaczonych wyjątków dla błędów, które nie powinny się zdarzyć, ale wykonaj. (Nie działa serwer, błędnie skonfigurowana ścieżka klasy, błąd składni SQL itd.) Facet od zarządzania serwerem IT lub programista, który właśnie przekazał zły SQL do funkcji prepareStatement() powinien wiedzieć, jak rozwiązać te problemy. Błędy powinny rozprzestrzeniać się do warstwy rejestrowania, aby informacje nie zostały utracone.