Odpowiedź

Mechanizm obsługi wyjątków przez try-catch-finally został dodany do Javy od samego początku rozwoju języka. Głównym celem jest zapewnienie strukturalnego zarządzania błędami, oddzielając kod roboczy od kodu obsługi błędów.

Problem: każde nietypowe lub błędne zachowanie prowadzi do rzucenia wyjątku (exception). Bez try-catch można go tylko przekazać wyżej w stosie wywołań. Tego podejścia program może się awaryjnie zakończyć.

Rozwiązanie — użycie try { } catch { } finally { }, co pozwala obsłużyć oczekiwane wyjątki i gwarantuje wykonanie działań końcowych (zwolnienie zasobów, zamknięcie plików, wycofanie transakcji).

Przykład kodu:

try {
    FileInputStream fin = new FileInputStream("test.txt");
    int data = fin.read();
} catch (IOException e) {
    System.out.println("Błąd podczas pracy z plikiem: " + e.getMessage());
} finally {
    fin.close();
}

Kluczowe cechy:

Blok try zawiera potencjalnie błędny kod
catch przechwytuje i obsługuje wyjątki
finally zawsze jest wykonywany, nawet przy return/exception

Pułapki w pytaniach.

Czy finally może nie zostać wykonany?

Tak, jeśli wewnątrz bloku jest System.exit(), proces zakończył się awaryjnie lub JVM "padła" fizycznie.

Czy można używać try-catch bez finally?

Tak, blok finally nie jest obowiązkowy. Ale jeśli wymagane jest zwolnienie zasobów, zwykle się go używa. Od Javy 7 wprowadzono try-with-resources.

Co się stanie, jeśli w finally wystąpi wyjątek?

Jeśli w finally wystąpi nowy błąd, "przysłoni" on oryginalny (jeżeli nie został przechwycony osobno), co może maskować problemy.

try { throw new RuntimeException("fail in try"); }
finally { throw new RuntimeException("fail in finally"); }
// Ostateczny stacktrace — tylko "fail in finally"

Typowe błędy i antywzorce

Ignorowanie wyjątku (catch(Exception e) {} puste)
Ponowne rzucenie bez podania przyczyny (throw e; bez new Exception(e))
Przerywanie finally (powrót lub rzucenie nowego Exception)

Przykład z życia

Negatywny przypadek

W projekcie blok finally zawierał kod, który sam mógł rzucać IOException. W przypadku błędu w try oryginalny wyjątek został całkowicie utracony, co znacznie utrudniało diagnozowanie błędów.

Zalety:

Gwarantowane zwolnienie zasobów

Wady:

Maskowanie błędów
Utrudnione debugowanie

Pozytywny przypadek

Zamiast finally zespół przeszedł na try-with-resources. Każdy zasób implementuje AutoCloseable, zwolnienie odbywa się automatycznie, wyjątki są logowane w dziennikach jako własne błędy.