Aby bać się błędów - nie pisz w Javie! Prawdopodobnie wiesz już coś o wyjątkach w Javie . Dziś przyda Ci się chociaż powierzchowna wiedza: przeanalizujemy klasę Error i specjalny rodzaj wyjątków, które „przerażają” wiele osób, pojawiając się w ich Stacktracach .

Na czele hierarchii wyjątków w Javie znajduje się klasa Throwable , która ma dwóch następców:

  • Wyjątek , który odpowiada za błędy w systemie.
  • A naszym dzisiejszym bohaterem jest Error , który odpowiada za błędy JVM.
    Warto powiedzieć, że to raczej nie są nawet błędy, a problemy, które zwykle nie zależą od dewelopera.

Co zrobić z błędem

Podczas łapania „błędów” nie będziesz mógł wykonywać żadnych akcji w bloku catch , poza logowaniem , ponieważ są to problemy samej maszyny JVM.

Logowanie to dobra rzecz: gdy pojawi się błąd podczas wykonywania programu, możesz zajrzeć do logów, zobaczyć przyczynę awarii i wiedzieć, co naprawić.

Ponieważ nie wiesz, jaki rodzaj błędu możesz napotkać podczas tworzenia kodu, nie ma sensu wpisywać żadnego konkretnego typu w bloku catch . Samo użycie klasy Error też nie jest najlepszym rozwiązaniem: w takim przypadku wyłapiesz tylko błędy.

Dlatego lepiej jest użyć klasy Throwable , która może przechwytywać zarówno wyjątki Error , jak i Exception . Jak to wygląda w praktyce?

Nieładnie tak pisać:

try {
    // Your code
} catch (OutOfMemoryError outOfMemoryError) {
    // Code to catch OutOfMemoryError
}
Pisanie w ten sposób też nie jest OK:

try {
    // Your code
} catch (Error error) {
    // Code to catch all Errors
}
Ale pisać tak - OK:

try {
    // Your code
} catch (Throwable throwable) {
    // Code to catch all Throwables
}

Drugą opcją obsługi błędów jest wyrzucanie ich dalej za pomocą słowa kluczowego throws na poziomie metody. Ta metoda jest używana w przypadkach, gdy Twój kod mógłby teoretycznie zgłosić błąd typu error i chcesz przekazać to wszystkim, którzy będą używać Twojego kodu, aby mogli go przetworzyć.

Powszechne błędy

Niektóre z najpopularniejszych błędów to klasy OutOfMemoryError i StackOverflowError .

OutOfMemoryError często pojawia się w przypadkach, gdy program nie ma wystarczającej ilości miejsca do tworzenia obiektów , Garbage Collector nie ma czasu na przetworzenie iw rezultacie - OutOfMemoryError .

W Javie nie można kontrolować usuwania obiektów, aby zapobiec wyciekom pamięci, ale nie można zaśmiecać, aby nie przeciążać Garbage Collectora i nie zanieczyszczać sterty (sterty).

Na przykład ten typ kodu wygeneruje dużo śmieci w pamięci:


while (true) {
    new Object();
}

Drugi błąd, o którym chcę ci powiedzieć, to StackOverflowError : generowany, gdy stos się przepełni. Ponieważ stos przechowuje głównie zmienne lokalne, parametry i wywołania metod, bardzo częstym powodem jest rekurencja lub rekurencyjne wywołanie metody:


public void foo() {
    foo();
}

Nowoczesne IDE często rekurencyjnie zgłaszają wywoływanie metod, aby uniknąć problemów podczas wykonywania programu.

Nie możesz naprawić programu, który zgłasza Error , ale możesz napisać kod, który nie zakończy się zgłoszeniem błędu i uszkodzeniem programu. Po prostu nie zaniedbuj pamięci, ostrożnie twórz obiekty i poprawnie wywołuj metody, a wtedy będzie mniej problemów w twoim kodzie.

Różnica między typami błędów i wyjątków

błąd Wyjątek
Nie można naprawić w bloku zaczepu Może być obsługiwany w bloku catch
Nie pojawi się w czasie kompilacji Może zostać złapany w czasie kompilacji
Problemy z JVM Problemy z logiką kodu
Wszystkie Błąd odznaczone zaznaczone i niezaznaczone

W Javie nie ma mowy bez wyjątków, ale nie należy się ich bać. Musisz tylko zrozumieć, co oznacza każdy z typów i wiedzieć, jak sobie z nimi poradzić. To wszystko na dzisiaj. Do zobaczenia!