Java: Wyjaśnienie WYJĄTKÓW zaznaczonych i niezaznaczonych

To ,czy coś jest "zaznaczonym wyjątkiem", nie ma nic wspólnego z tym, czy go złapiesz, czy z tym, co robisz w bloku. To własność klas WYJĄTKÓW. Wszystko, co jest podklasą Exception except for RuntimeException i jego podklasy są wyjątkami sprawdzonymi.

Kompilator Javy wymusza wyłapywanie sprawdzonych wyjątków lub deklarowanie ich w sygnaturze metody. Miało to poprawić bezpieczeństwo programu, ale większość uważa, że nie warto problemy projektowe, które stwarza.

Dlaczego dopuszczają wyjątek w górę? Isnt obsługuje błąd im szybciej lepiej? Dlaczego bubble up?

Ponieważ to jest cały punkt WYJĄTKÓW. Bez tej możliwości nie potrzebowalibyście WYJĄTKÓW. Umożliwiają one obsługę błędów na wybranym poziomie, a nie zmuszają do radzenia sobie z nimi metodami niskopoziomowymi, w których pierwotnie występują.

1. Czy powyższe rozważenie jest wyjątkiem zaznaczonym? Nie. Fakt, że obsługujesz wyjątek, nie czyni go wyjątkiem sprawdzonym, jeśli jest to wyjątek RuntimeException.

2. Czy RuntimeException jest niezaznaczonym wyjątkiem? Tak

Zaznaczone wyjątki są podklasami Javy.lang.Wyjątek Niezaznaczone wyjątki są podklasami Javy.lang.RuntimeException

Wywołania rzucające zaznaczone wyjątki muszą być zamknięte w bloku try{} lub obsługiwane na poziomie powyżej w wywołaniu metody. W takim przypadku bieżąca metoda musi zadeklarować, że wyrzuca wspomniane wyjątki, aby wywołujący mogli dokonać odpowiednich ustaleń w celu obsługi wyjątku.

P: Czy powinienem dokładnie wyjątek czy maskowanie go za pomocą wyjątku?

O: tak jest to bardzo dobre pytanie i ważne rozważenie projektu. Wyjątek klasy jest bardzo ogólną klasą wyjątków i może być używany do zawijania wewnętrznego niskiego wyjątki poziomu. Lepiej Utwórz niestandardowy wyjątek i zawiń go w środku. Ale, i jeden duży - nigdy przenigdy niejasne w podstawowej pierwotnej przyczyny. For ex, Dont ever do following -

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException("Cannot login!!"); //<-- Eat away original root cause, thus obscuring underlying problem.
}

Zamiast tego wykonaj następujące czynności:

try {
     attemptLogin(userCredentials);
} catch (SQLException sqle) {
     throw new LoginFailureException(sqle); //<-- Wrap original exception to pass on root cause upstairs!.
}

Usunięcie pierwotnej przyczyny zakopuje faktyczną przyczynę poza odzyskiwaniem jest koszmarem dla zespołów wsparcia produkcji, gdzie wszystko, do czego mają dostęp, to Dzienniki aplikacji i komunikaty o błędach. Chociaż ten ostatni jest lepszym projektem, ale wiele osób nie używaj go często, ponieważ deweloperzy po prostu nie przekazują podstawowej Wiadomości do rozmówcy. Więc zanotuj stanowczo: Always pass on the actual exception z powrotem, niezależnie od tego, czy zawinięte w jakikolwiek wyjątek specyficzny dla aplikacji.

On try-catching RuntimeExceptions

RuntimeExceptions co do zasady nie należy próbować chwytać. Zazwyczaj sygnalizują błąd programowania i powinny być pozostawione w spokoju. Zamiast tego programista powinien sprawdzić stan błędu przed wywołaniem jakiegoś kodu, który może spowodować RuntimeException. Dla ex:

try {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} catch (NullPointerException npe) {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

if (userObject != null) {
    setStatusMessage("Hello Mr. " + userObject.getName() + ", Welome to my site!);
} else {
   sendError("Sorry, your userObject was null. Please contact customer care.");
}

Ale są chwile, kiedy takie sprawdzanie błędów jest drogie, takie jak formatowanie liczb, rozważ to -

try {
    String userAge = (String)request.getParameter("age");
    userObject.setAge(Integer.parseInt(strUserAge));
} catch (NumberFormatException npe) {
   sendError("Sorry, Age is supposed to be an Integer. Please try again.");
}

Tutaj sprawdzanie błędów wstępnego wywołania nie jest warte wysiłku, ponieważ zasadniczo oznacza powielenie całego kodu konwersji string-to-integer wewnątrz metody parseInt ()-i jest podatne na błędy, jeśli jest zaimplementowane przez programistę. Więc to lepiej jest po prostu pozbyć się try-catch.

Tak więc NullPointerException i NumberFormatException są obiema wyrażeniami RuntimeExceptions, przechwytywanie NullPointerException powinno zostać zastąpione wdzięcznym sprawdzeniem null, podczas gdy zalecam bezpośrednie przechwytywanie NumberFormatException, aby uniknąć ewentualnego wprowadzenia kodu podatnego na błędy.

1 . Jeśli nie masz pewności co do wyjątku, sprawdź API:

 java.lang.Object
 extended by java.lang.Throwable
  extended by java.lang.Exception
   extended by java.lang.RuntimeException  //<-NumberFormatException is a RuntimeException  
    extended by java.lang.IllegalArgumentException
     extended by java.lang.NumberFormatException

2 . Tak, i każdy wyjątek, który go rozszerza.

3 . Nie ma potrzeby, aby złapać i rzucić ten sam wyjątek. W tym przypadku można wyświetlić okno dialogowe nowego pliku.

4 . FileNotFoundException jest już zaznaczonym wyjątkiem.

5 . Jeśli oczekuje się, że metoda wywołująca someMethod, aby złapać wyjątek, ten ostatni może zostać wyrzucony. To po prostu "podaje piłkę". Przykład tego użycie byłoby możliwe, jeśli chcesz wrzucić go do własnych metod prywatnych, a zamiast tego obsłużyć wyjątek w metodzie publicznej.

Dobrą lekturą jest sam Oracle doc: http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html

Dlaczego projektanci zdecydowali się wymusić metodę, która określi wszystkie nieobciążone, sprawdzone wyjątki, które można wrzucić w jej zakres? Każdy wyjątek, który może być wyrzucony przez metodę, jest częścią publicznej metody interfejs programowania. Ci, którzy wywołują metodę, muszą wiedzieć o wyjątkach, które metoda może rzucać, aby mogli zdecydować, co z nimi zrobić. Wyjątki te są tak samo częścią interfejsu programowania tej metody, jak jej parametry i wartość zwracana.

Następne pytanie może brzmieć: "jeśli tak dobrze jest udokumentować API metody, włączając w to wyjątki, które może ona rzucać, dlaczego nie określić również WYJĄTKÓW runtime?"Wyjątki Runtime reprezentują problemy, które są wynikiem problem programistyczny, a jako taki, kodu klienta API nie można racjonalnie oczekiwać, aby odzyskać od nich lub obsłużyć je w jakikolwiek sposób. Problemy te obejmują wyjątki arytmetyczne, takie jak dzielenie przez zero; wyjątki wskaźnikowe, takie jak próba uzyskania dostępu do obiektu przez odniesienie null; oraz wyjątki indeksujące, takie jak próba uzyskania dostępu do elementu tablicy przez indeks, który jest zbyt duży lub zbyt mały.

Jest też ważna informacja w Java Specyfikacja Języka:

Klasy WYJĄTKÓW sprawdzonych nazwane w klauzuli throws są częścią umowy pomiędzy wykonawcą a użytkownikiem metody lub konstruktora .

Najważniejsze IMHO jest to, że ty Możesz złapać dowolne RuntimeException, ale nie jesteś do tego zobowiązany i w rzeczywistości implementacja nie jest wymagana do utrzymania tych samych niezabezpieczonych wyjątków, ponieważ nie są one częścią umowy.

1) nie, wyjątek NumberFormatException jest niezaznaczonym wyjątkiem. Nawet jeśli go złapałeś (nie musisz tego robić), jest on niezaznaczony. Jest to podklasa IllegalArgumentException, która jest podklasą RuntimeException.

2) RuntimeException jest korzeniem wszystkich niezaznaczonych WYJĄTKÓW. Każda podklasa RuntimeException jest odznaczona. Wszystkie inne wyjątki i przedmioty do wyrzucenia są sprawdzane, z wyjątkiem błędów (które znajdują się w polu Throwable).

3/4) możesz zaalarmować użytkownika że wybrali nieistniejący plik i prosili o nowy. Lub po prostu przestań informować użytkownika, że wprowadził coś nieprawidłowego.

5) rzucanie i łapanie 'WYJĄTKÓW' to zła praktyka. Ale bardziej ogólnie, możesz rzucać inne wyjątki, aby rozmówca mógł zdecydować, jak sobie z tym poradzić. Na przykład, jeśli napisałeś bibliotekę do obsługi odczytu jakiegoś pliku wejściowego, a twoja metoda została przekazana nieistniejącemu plikowi, nie masz pojęcia, jak to zrobić. Dzwoniący chce zapytać ponownie czy zrezygnować? Więc ty wyrzuć wyjątek z powrotem do rozmówcy.

W wielu przypadkach występuje niezaznaczony wyjątek, ponieważ programista nie zweryfikował danych wejściowych (w przypadku NumberFormatException w pierwszym pytaniu). Dlatego jego opcjonalne, aby je złapać, ponieważ istnieją bardziej eleganckie sposoby, aby uniknąć generowania tych wyjątków.

Sprawdzone - Sprawdzone w czasie kompilacji.

Np.. FileOperations

Niezaznaczone-z powodu złych danych. Sprawdzam czas pracy.

Np..

String s = "abc";
Object o = s;
Integer i = (Integer) o;

Exception in thread "main" java.lang.ClassCastException: java.lang.String cannot be cast to java.lang.Integer
    at Sample.main(Sample.java:9)

Tutaj wyjątek wynika ze złych danych i w żaden sposób nie można ich określić podczas kompilacji.

Zaznaczone wyjątki są sprawdzane podczas kompilacji przez JVM i związane z nim zasoby (pliki / db/stream / socket itp.). Motywem wyjątku checked jest to, że podczas kompilacji, jeśli zasoby nie są dostępne, aplikacja powinna zdefiniować alternatywne zachowanie do obsługi tego w bloku catch/finally.

Niezaznaczone wyjątki to błędy czysto programistyczne, błędne obliczenia, null danych lub nawet awarie logiki biznesowej mogą prowadzić do wyjątków w czasie wykonywania. Jego absolutnie w porządku do obsługa / łapanie niezaznaczonych WYJĄTKÓW w kodzie.

Wyjaśnienie zaczerpnięte z http://coder2design.com/java-interview-questions/

Chcę tylko dodać trochę uzasadnienia, aby w ogóle nie używać zaznaczonych WYJĄTKÓW. Nie jest to pełna odpowiedź, ale czuję, że odpowiada na część twojego pytania i uzupełnia wiele innych odpowiedzi.

Ilekroć występują zaznaczone wyjątki, istnieje throws CheckedException gdzieś w sygnaturze metody (CheckedException może być każdy sprawdzony wyjątek). Podpis nie rzuca wyjątku, rzucanie wyjątków jest aspektem implementacji. Interfejsy, podpisy metod, klasy nadrzędne, wszystkie te rzeczy nie powinny zależeć od ich implementacji. Użycie tutaj sprawdzonych WYJĄTKÓW (w rzeczywistości fakt, że musisz zadeklarować throws w podpisie metody) wiąże interfejsy wyższego poziomu z implementacjami tych interfejsów.

Let ' s have a nice and clean interface like this

public interface IFoo {
    public void foo();
}

Teraz możemy napisać wiele implementacji metody foo(), jak te

public class Foo implements IFoo {
    @Override
    public void foo() {
        System.out.println("I don't throw and exception");
    }
}

public class Bar implements IFoo {
    @Override
    public void foo() {
        //I'm using InterruptedExcepton because you probably heard about it somewhere. It's a checked exception. Any checked exception will work the same.
        throw new InterruptedException();
    }
}

Ten pasek klasy nie będzie kompilowany. Ponieważ InterruptedException jest wyjątkiem zaznaczonym, musisz go przechwycić (za pomocą metody try-catch wewnątrz metody foo ()) lub zadeklarować, że go wyrzucasz (dodając throws InterruptedException do sygnatury metody). Ponieważ nie chcę tutaj przechwytywać tego wyjątku (chcę, aby rozprzestrzeniał się w górę, abym mógł sobie z nim poradzić gdzie indziej), zmieńmy podpis.

public class Bar implements IFoo {
    @Override
    public void foo() throws InterruptedException {
        throw new InterruptedException();
    }
}

Ten pasek klas też się nie skompiluje! Bar ' s method foo() nie nadpisuje metody IFoo foo (), ponieważ ich sygnatury są różne. Mógłbym usunąć adnotację @ Override, ale chcę zaprogramować na interfejsie IFoo jak IFoo foo;, a później zdecydować, której implementacji chcę użyć, jak foo = new Bar();. Jeśli metoda Bar foo () nie nadpisuje metody Foo IFoo, to gdy wykonam foo.foo();, nie wywoła implementacji Foo () Bara.

Aby Bar 's public void foo() throws InterruptedException nadpisać ifoo' s public void foo() muszę dodać throws InterruptedException do podpisu metody IFoo. To jednak spowoduje problemy z moją klasą Foo, ponieważ podpis metody foo () różni się od podpisu metody IFoo. Co więcej, jeśli dodałbym throws InterruptedException do metody Foo foo (), otrzymałbym kolejny błąd stwierdzający, że metoda foo Foo () deklaruje, że wyrzuca przerywaną wyjątek, ale nigdy nie wyrzuca przerywanej wyjątku.

Jak widzisz (jeśli dobrze to wyjaśniłem), fakt, że rzucam sprawdzony wyjątek, taki jak InterruptedException, zmusza mnie do powiązania interfejsu IFoo z jedna z jego implementacji, co z kolei powoduje spustoszenie w innych implementacjach IFoo!

Jest to jeden wielki powód, dla którego zaznaczone wyjątki są złe. W kapslach.

Jednym z rozwiązań jest przechwycenie zaznaczonego wyjątku, zawinięcie go w niezaznaczony wyjątek i wyrzucenie niezaznaczonego wyjątku.

Aby odpowiedzieć na ostatnie pytanie (inni wydają się dokładnie odpowiedzieć powyżej), " Czy powinienem zrobić bańkę z dokładnym wyjątkiem lub zamaskować go za pomocą wyjątku?"

Zakładam, że masz na myśli coś takiego:

public void myMethod() throws Exception {
    // ... something that throws FileNotFoundException ...
}

Nie, zawsze deklaruj najbardziej precyzyjny wyjątek możliwy, lub listę takich. Wyjątki, które deklarujesz jako zdolne do rzucania, są częścią Umowy między Twoją metodą a rozmówcą. Rzucanie "FileNotFoundException" oznacza, że możliwe jest nazwa pliku nie jest poprawna i plik nie zostanie znaleziony; wywołujący będzie musiał to inteligentnie obsłużyć. Rzucanie "wyjątku" oznacza " Hej, sh * t happens. Zgoda.", Co jest bardzo słabym API.

W komentarzach do pierwszego artykułu jest kilka przykładów, gdzie "rzuca wyjątek" jest ważną i rozsądną deklaracją, ale nie jest tak w przypadku większości "normalnych" kodów, które kiedykolwiek napiszesz.

• Java rozróżnia dwie kategorie WYJĄTKÓW (zaznaczone i niezaznaczone)
• Java wymusza catch lub deklarowane wymagania dla sprawdzonych WYJĄTKÓW
Typ wyjątku określa, czy wyjątek jest zaznaczony czy niezaznaczony.
• Wszystkie typy wyjątków, które są bezpośrednimi lub pośrednimi podklasami klasy RuntimeException są wyjątkami niezaznaczonymi.
• wszystkie klasy, które dziedziczą z wyjątku klasy, ale nie RuntimeException są uważane za sprawdzane wyjątki.
• klasy dziedziczące z błędu klasy są uważane za niezaznaczone.
• kompilator sprawdza każde wywołanie i opóźnienie metody w celu ustalenia, czy metoda rzuca zaznaczony wyjątek.
  • jeśli tak, kompilator zapewnia, że wyjątek zostanie przechwycony lub zadeklarowany w klauzuli throws.
• aby spełnić deklarowaną część wymogu catch-or-declare, metoda, która generuje wyjątek musi zawierać klauzulę throws zawierającą zaznaczone-wyjątek.
• klasy WYJĄTKÓW są definiowane do sprawdzenia, gdy są uważane za wystarczająco ważne, aby złapać lub zadeklarować.

Dlaczego dopuszczają wyjątek? Czy szybciej nie poradzimy sobie z błędem? Dlaczego bubble up?

Na przykład powiedzmy, że masz jakąś aplikację Klient-Serwer i klient złożył prośbę o jakiś zasób, którego nie można było znaleźć lub o coś innego błąd, który mógł wystąpić po stronie serwera podczas przetwarzania żądania użytkownika,to obowiązkiem serwera jest powiedzieć klientowi, dlaczego nie mógł uzyskać rzeczy, o którą prosił, więc aby to osiągnąć na serwerze. po stronie serwera, kod jest zapisywany w celu wyrzucenia wyjątku za pomocą słowa kluczowego throw zamiast połykania lub obsługi GO.jeśli serwer ją obsłuży/połknie, wtedy nie będzie szans na poinformowanie klienta, że wystąpił błąd.

Uwaga: aby dokładnie opisać jaki błąd wystąpił, możemy utworzyć własny obiekt Exception i wrzucić go do klienta.

Mój absolute favorite Opis różnicy między wyjątkami zaznaczonymi i zaznaczonymi znajduje się w artykule Java Tutorial trail, " wyjątki zaznaczone - kontrowersje" (sorry to get all elementary on this post - but, hey, the basics are sometimes the best): {]}

Oto najważniejsze wytyczne: jeśli klient może rozsądnie być oczekuje się, że zostanie odzyskany z wyjątku, uczyni go wyjątkiem sprawdzonym. Jeśli klient nie może nic zrobić, aby odzyskać od wyjątku, uczynić go unchecked exception

Sednem "jakiego typu wyjątek wyrzucić" jest semantyka (w pewnym stopniu) i powyższy cytat zapewnia i doskonałą wytyczną(stąd nadal jestem zdumiony poglądem, że C# pozbył się sprawdzonych WYJĄTKÓW-szczególnie, że Liskov argumentuje o ich przydatności).

Reszta staje się wtedy logiczna: na jakie wyjątki kompilator oczekuje ode mnie wyraźnej odpowiedzi? Te, od których oczekujesz od klienta wyzdrowiej.

Wyjątki Runtime Wyjątki uruchomieniowe są określane jako wyjątki niezaznaczone. Wszystkie inne wyjątki są zaznaczonymi wyjątkami i nie pochodzą z Javy.lang.RuntimeException.

Zaznaczone Wyjątki Zaznaczony wyjątek musi zostać złapany gdzieś w Twoim kodzie. Jeśli wywołasz metoda, która rzuca zaznaczony wyjątek, ale nie wyłapuje zaznaczonego wyjątku gdzieś Twój Kod się nie skompiluje. Dlatego nazywa się je sprawdzonymi. wyjątki: kompilator sprawdza aby upewnić się, że są obsługiwane lub zadeklarowane.

Wiele metod w API Javy wyrzuca zaznaczone wyjątki, więc często będziesz pisał programy obsługi wyjątków, aby poradzić sobie z wyjątkami generowanymi przez metody, których nie napisałeś.

Oto prosta zasada, która może pomóc ci podjąć decyzję. Jest to związane z tym, jak interfejsy są używane w Javie.

Weź swoją klasę i wyobraź sobie zaprojektowanie dla niej interfejsu tak, aby interfejs opisywał funkcjonalność klasy, ale żadnej z podstawowych implementacji (jak interfejs powinien). Udawaj, że możesz zaimplementować klasę w inny sposób.

Spójrz na metody interfejsu i rozważ wyjątki, które mogą rzucać:

Jeśli wyjątek może być rzucone przez metodę, niezależnie od podstawowej implementacji (innymi słowy, opisuje tylko funkcjonalność), to prawdopodobnie powinien być sprawdzony wyjątek w interfejsie.

Jeśli wyjątek jest spowodowany przez podstawową implementację, nie powinien znajdować się w interfejsie. W związku z tym musi to być albo niezaznaczony wyjątek w twojej klasie (ponieważ niezaznaczone wyjątki nie muszą pojawiać się w sygnaturze interfejsu), albo musisz go zawijać i rethrow jako zaznaczony wyjątek, który jest częścią metody interfejsu.

Aby zdecydować, czy należy zawinąć i rethrow, należy ponownie rozważyć, czy jest sens, aby użytkownik interfejsu musiał natychmiast obsłużyć warunek wyjątku, czy wyjątek jest tak ogólny, że nic nie można z tym zrobić i powinien rozprzestrzeniać się w górę stosu. Czy owinięty wyjątek ma sens, gdy jest wyrażony jako funkcjonalność nowego interfejsu, który definiujesz, czy jest tylko nośnikiem dla worka możliwych błędów, które może się zdarzyć również z innymi metodami? Jeśli pierwszy z nich, nadal może być wyjątkiem zaznaczonym, w przeciwnym razie powinien być odznaczony.

Zazwyczaj nie należy planować" bubble-up " WYJĄTKÓW(catch i rethrow). Albo wyjątek powinien być obsługiwany przez wywołującego (w tym przypadku jest sprawdzany) albo powinien przejść aż do obsługi wysokiego poziomu (w tym przypadku jest to najprostsze, jeśli jest zaznaczone).

Myślę, że zaznaczone wyjątki są dobrym przypomnieniem dla programisty, który korzysta z zewnętrznej biblioteki, że w wyjątkowych sytuacjach może pójść źle z kodem z tej biblioteki.

Przeczytaj więcej o wyjątkach zaznaczonych i niezaznaczonych tutaj http://learnjava.dzisiaj/2015/11/checked-vs-unchecked-exceptions /

Aby zaznaczyć, że jeśli rzucisz zaznaczony wyjątek w kodzie, a haczyk jest kilka poziomów wyżej, musisz zadeklarować wyjątek w podpisie każdej metody między tobą a haczykiem. Enkapsulacja jest więc przerwana, ponieważ wszystkie funkcje na ścieżce throw muszą wiedzieć o szczegółach tego wyjątku.

W skrócie, wyjątki, które twój moduł lub powyższe moduły mają obsługiwać podczas wykonywania, nazywane są wyjątkami wyboru, inne są niezaznaczonymi wyjątkami, które są RuntimeException LUB Error. W tym filmie wyjaśniono wyjątki zaznaczone i niezaznaczone w Javie. https://www.youtube.com/watch?v=ue2pOqLaArw

Wszystkie z nich są zaznaczonymi wyjątkami. Niezaznaczone wyjątki są podklasami RuntimeException. Decyzja nie polega na tym, jak sobie z nimi radzić, tylko na tym, czy Twój kod je wyrzuci. Jeśli nie chcesz, aby kompilator informował Cię, że nie obsłużyłeś wyjątku, użyj wyjątku niezaznaczonego (podklasa RuntimeException). Należy je zapisać w sytuacjach, z których nie można odzyskać, takich jak błędy pamięci i tym podobne.

Jeśli komuś zależy na jeszcze jednym dowodzie niechęci do sprawdzonych WYJĄTKÓW, zobacz kilka pierwszych akapitów popularnej biblioteki JSON:

" chociaż jest to wyjątek sprawdzony, rzadko można go odzyskać. Większość wywołujących powinna po prostu zawinąć ten wyjątek w niezaznaczony wyjątek i napisać: "

Więc dlaczego ktoś miałby zmuszać programistów do sprawdzania wyjątku, skoro zamiast tego powinniśmy "po prostu go zawijać"? lol

Http://developer.android.com/reference/org/json/JSONException.html

Sprawdzone Wyjątki :

• Wyjątki, które są sprawdzane przez kompilator pod kątem sprawnego wykonania programu w czasie wykonywania, nazywane są wyjątkami sprawdzonymi.

• Występują one w czasie kompilacji.

• Je ¶ li nie s ± one obs3ugiwane poprawnie, daj± b3êd czasu kompilacji(nie wyj ± tek).

• Wszystkie podklasy klasy Exception oprócz RuntimeException są zaznaczonymi wyjątkami.

  Przykład Hipotetyczny - Załóżmy wyjeżdżasz z domu na egzamin, ale jeśli sprawdzisz, czy odebrałeś bilet w domu (czas kompilacji), nie będzie żadnego problemu w sali egzaminacyjnej (runtime).

Unchecked Exception :

• Wyjątki, które nie są sprawdzane przez kompilator, nazywane są wyjątkami Niezaznaczonymi.

• Występują one w czasie wykonywania.

• Jeśli te wyjątki nie są obsługiwane poprawnie, nie powodują błędu w czasie kompilacji. Ale program będzie być przedwcześnie zakończone w czasie wykonywania.

• Wszystkie podklasy RunTimeException i Error są wyjątkami niezaznaczonymi.

  przykład hipotetyczny - Załóżmy, że jesteś w swojej sali egzaminacyjnej, ale jakoś Twoja szkoła miała wypadek pożarowy (czyli w czasie wykonywania), w którym nie możesz nic zrobić w tym czasie, ale środki ostrożności można zrobić przed (czas kompilacji).

Wszystkie wyjątki muszą być zaznaczonymi wyjątkami.

1. Niezaznaczone wyjątki to nieograniczone Goto. A nieograniczone Goto są uważane za złą rzecz.

2. Niezaznaczone wyjątki przerywają enkapsulację. Aby je poprawnie przetworzyć, wszystkie funkcje w drzewie wywołań między miotaczem a łapaczem muszą być znane, aby uniknąć błędów.

3. Wyjątkami są błędy w funkcji, która je rzuca, ale nie błędy w funkcji, która je przetwarza. Celem wyjątkami jest danie programowi drugiej szansy poprzez odroczenie decyzji, czy jest to błąd, czy nie, do innego kontekstu. Tylko w innym kontekście można podjąć właściwą decyzję.