Odpowiedzi:
Zasadniczo wyjątki RuntimeException są wyjątkami, którym można programowo zapobiec. Np NullPointerException, ArrayIndexOutOfBoundException. Jeśli zaznaczysz nullprzed wywołaniem dowolnej metody, NullPointerExceptionnigdy by się nie zdarzyło. Podobnie ArrayIndexOutOfBoundExceptionnigdy się nie zdarzy, jeśli najpierw sprawdzisz indeks. RuntimeExceptionnie są sprawdzane przez kompilator, więc jest to czysty kod.
EDYCJA : W dzisiejszych czasach ludzie wolą, RuntimeExceptionponieważ produkuje czysty kod. Jest to całkowicie osobisty wybór.
RuntimeExceptionjest to, że jest to proste i eliminuje potrzebę zastanawiania się nad różnicami między sprawdzonymi i niesprawdzonymi wyjątkami. Myślę, że wyłapywanie wyjątków czasu wykonywania jest okropnym pomysłem, ponieważ wychwytujesz wyjątki niemożliwe do odzyskania, takie jak NullPointerException.
W Javie istnieją dwa typy wyjątków: sprawdzone wyjątki i niezaznaczone wyjątki. Sprawdzony wyjątek musi być obsługiwany jawnie przez kod, podczas gdy niezaznaczony wyjątek nie musi być jawnie obsługiwany.
W przypadku zaznaczonych wyjątków musisz albo umieścić blok try / catch wokół kodu, który potencjalnie może wyrzucić wyjątek, albo dodać do metody klauzulę „throws”, aby wskazać, że metoda może zgłosić ten typ wyjątku (który musi być obsługiwane w klasie wywołującej lub wyższej).
Każdy wyjątek pochodzący od „wyjątku” jest sprawdzonym wyjątkiem, podczas gdy klasa wywodząca się z RuntimeException nie jest zaznaczona. RuntimeExceptions nie muszą być jawnie obsługiwane przez kod wywołujący.
Przed patrząc na różnicę między java.lang.RuntimeExceptioni java.lang.Exceptionklas, trzeba znać Exceptionhierarchię. Zarówno Exceptioni Errorklasy pochodzą z klas Throwable(co wynika z klasy Object). A klasa RuntimeExceptionwywodzi się z klasy Exception.
Wszystkie wyjątki pochodzą od Exceptionlub RuntimeException.
Wszystkie wynikające z RuntimeExceptionnich wyjątki są nazywane niesprawdzonymi wyjątkami. Wszystkie pozostałe wyjątki są sprawdzane . Zaznaczony wyjątek musi zostać przechwycony gdzieś w kodzie, w przeciwnym razie nie zostanie skompilowany. Dlatego nazywane są sprawdzonymi wyjątkami. Z drugiej strony, z nie zaznaczonymi wyjątkami, metoda wywołująca nie jest zobowiązana do jej obsługi ani deklarowania.
Dlatego wszystkie wyjątki, które kompilator zmusza do obsługi, pochodzą bezpośrednio, java.lang.Exceptiona wszystkie inne, z których kompilator nie zmusza cię do obsługi, pochodzą java.lang.RuntimeException.
Poniżej przedstawiono niektóre z bezpośrednich znanych podklas RuntimeException .
AnnotationTypeMismatchException,
ArithmeticException,
ArrayStoreException,
BufferOverflowException,
BufferUnderflowException,
CannotRedoException,
CannotUndoException,
ClassCastException,
CMMException,
ConcurrentModificationException,
DataBindingException,
DOMException,
EmptyStackException,
EnumConstantNotPresentException,
EventException,
IllegalArgumentException,
IllegalMonitorStateException,
IllegalPathStateException,
IllegalStateException,
ImagingOpException,
IncompleteAnnotationException,
IndexOutOfBoundsException,
JMRuntimeException,
LSException,
MalformedParameterizedTypeException,
MirroredTypeException,
MirroredTypesException,
MissingResourceException,
NegativeArraySizeException,
NoSuchElementException,
NoSuchMechanismException,
NullPointerException,
ProfileDataException,
ProviderException,
RasterFormatException,
RejectedExecutionException,
SecurityException,
SystemException,
TypeConstraintException,
TypeNotPresentException,
UndeclaredThrowableException,
UnknownAnnotationValueException,
UnknownElementException,
UnknownTypeException,
UnmodifiableSetException,
UnsupportedOperationException,
WebServiceException
Wyjątek jest sprawdzany, a RuntimeException nie jest zaznaczony.
Zaznaczone oznacza, że kompilator wymaga, abyś obsługiwał wyjątek w catch lub zadeklarował metodę jako rzucającą go (lub jedną z jego nadklas).
Zasadniczo wyrzuć sprawdzony wyjątek, jeśli oczekuje się, że wywołujący interfejs API obsłuży wyjątek, i niesprawdzony wyjątek, jeśli jest to coś, co wywołujący normalnie nie byłby w stanie obsłużyć, na przykład błąd z jednym z parametrów, np. Programowanie błąd.
Klasy wyjątków środowiska wykonawczego (RuntimeException i jego podklasy) są zwolnione z sprawdzania czasu kompilacji, ponieważ kompilator nie może ustalić, że wyjątki czasu wykonywania nie mogą wystąpić. (z JLS).
W projektowanych klasach należy podklasować wyjątek i zgłaszać jego instancje, aby zasygnalizować wszelkie wyjątkowe scenariusze. W ten sposób będziesz wyraźnie sygnalizował klientom swojej klasy, że użycie twojej klasy może spowodować wyjątek i muszą podjąć kroki, aby obsłużyć te wyjątkowe scenariusze.
Poniższe fragmenty kodu wyjaśniają ten punkt:
//Create your own exception class subclassing from Exception
class MyException extends Exception {
public MyException(final String message) {
super(message);
}
}
public class Process {
public void execute() {
throw new RuntimeException("Runtime");
}
public void process() throws MyException {
throw new MyException("Checked");
}
}
W powyższej definicji klasy Process , metoda executemoże zgłosić wyjątek RuntimeException, ale deklaracja metody nie musi określać, że generuje wyjątek RuntimeException .
Metoda processzgłasza sprawdzony wyjątek i powinna zadeklarować, że wyrzuci sprawdzony wyjątek rodzaju MyException, a nie zrobienie tego będzie błędem kompilacji.
Powyższa definicja klasy wpłynie również na kod korzystający z klasy Process .
Wywołanie new Process().execute()jest prawidłowym wywołaniem, w którym jako wywołanie formularza
new Process().process()powoduje błąd kompilacji. Wynika to z tego, że kod klienta powinien podjąć odpowiednie kroki MyException(powiedzmy, że call to process () może być ujęte w bloku try / catch).
Prawidłowe korzystanie z RuntimeException?
Z niesprawdzonych wyjątków - Kontrowersje :
Jeśli można zasadnie oczekiwać, że klient wyzdrowieje z wyjątku, uczyń go sprawdzonym wyjątkiem. Jeśli klient nie może nic zrobić w celu odzyskania od wyjątku, uczyń z niego niesprawdzony wyjątek.
Zauważ, że niesprawdzony wyjątek pochodzi od, RuntimeExceptiona sprawdzony wyjątek pochodzi od Exception.
Po co rzucać, RuntimeExceptionjeśli klient nie może nic zrobić, aby odzyskać od wyjątku? Artykuł wyjaśnia:
Wyjątki w czasie wykonywania reprezentują problemy wynikające z problemów programistycznych i dlatego nie można oczekiwać, że kod klienta API odzyska od nich lub w jakikolwiek sposób sobie z nimi poradzi. Takie problemy obejmują wyjątki arytmetyczne, takie jak dzielenie przez zero; wyjątki wskaźnika, takie jak próba dostępu do obiektu przez odwołanie zerowe; oraz indeksowanie wyjątków, takich jak próba dostępu do elementu tablicy za pośrednictwem indeksu, który jest zbyt duży lub zbyt mały.
Z dokumentacji Oracle:
Oto podstawowa wytyczna: jeśli można zasadnie oczekiwać, że klient wyzdrowieje z wyjątku, ustaw go jako sprawdzony wyjątek. Jeśli klient nie może nic zrobić w celu odzyskania od wyjątku, uczyń z niego niesprawdzony wyjątek.
Wyjątki czasu wykonywania reprezentują problemy wynikające z problemów programistycznych i jako takie nie można oczekiwać, że kod klienta API odzyska od nich lub w jakikolwiek sposób sobie z nimi poradzi.
RuntimeExceptions są jak „wyjątki z powodu nieprawidłowego użycia interfejsu API” przykłady runtimeexceptions: IllegalStateException, NegativeArraySizeException, NullpointerException
Z wyjątkami musisz to wyraźnie złapać, ponieważ nadal możesz coś zrobić, aby odzyskać. Przykładami wyjątków są: IOException, TimeoutException, PrintException ...
W prostych słowach, jeśli klient / użytkownik może odzyskać z wyjątku wtedy zrobić to sprawdzone Wyjątek , jeśli klient nie może nic, aby odzyskać od wyjątek następnie dokonać jej Nieograniczony RuntimeException . Np. RuntimeException byłby błędem programistycznym, takim jak dzielenie przez zero, żaden użytkownik nie może nic na to poradzić poza samym programistą, wtedy jest to RuntimeException .
RuntimeException to klasa potomna klasy Exception
Jest to jedna z wielu klas potomnych klasy Wyjątek. RuntimeException jest nadklasą tych wyjątków, które mogą zostać zgłoszone podczas normalnej pracy wirtualnej maszyny Java. Metoda nie jest wymagana do deklarowania w swojej klauzuli throws żadnych podklas RuntimeException, które mogą zostać wygenerowane podczas wykonywania metody, ale nie zostaną przechwycone.
Hierarchia jest
java.lang.Object
--- java.lang.Throwable
------- java.lang.Exception
------------- java.lang.RuntimeException
Wyjątki to dobry sposób na obsługę nieoczekiwanych zdarzeń w przepływie aplikacji. RuntimeException nie jest zaznaczone przez kompilator, ale możesz preferować stosowanie wyjątków, które rozszerzają klasę wyjątków, do kontrolowania zachowania klientów interfejsu API, ponieważ są oni zobowiązani do wychwytywania błędów podczas kompilacji. Tworzy również dobrą dokumentację.
Jeśli chcesz uzyskać czysty interfejs, użyj dziedziczenia, aby podklasować różne typy wyjątków w twojej aplikacji, a następnie ujawnić wyjątek nadrzędny.
Istnieją dwa rodzaje wyjątków. Możesz odzyskać z zaznaczonego wyjątku, jeśli otrzymasz taki wyjątek. Wyjątek środowiska wykonawczego jest nie do odzyskania, wyjątkami środowiska wykonawczego są błędy programistyczne, a programista powinien zająć się tym podczas pisania kodu, a dalsze wykonywanie tego może dać niepoprawny wynik. Wyjątki czasu wykonywania dotyczą naruszenia warunków wstępnych np. masz tablicę o rozmiarze 10 i próbujesz uzyskać dostęp do 11. elementu, spowoduje to wygenerowanie wyjątku ArrayIndexOutOfBoundException
Wyjątkiem zdefiniowanym przez użytkownika może być wyjątek sprawdzany lub wyjątek niezaznaczony, zależy to od klasy, do której się rozszerza.
Wyjątkiem zdefiniowanym przez użytkownika może być niestandardowy wyjątek sprawdzany, jeśli rozszerza się on na klasę wyjątków
Wyjątek zdefiniowany przez użytkownika może być niestandardowym wyjątkiem niezaznaczonym, jeśli rozszerza się na klasę wyjątków czasu wykonywania.
Zdefiniuj klasę i uczyń ją dzieckiem wyjątku lub wyjątku czasu wykonywania