Java gestionează erorile cu try/catch/finally și distinge în mod unic checked exceptions (trebuie declarate sau tratate) de unchecked exceptions (runtime, nu sunt obligatorii). Această distincție este centrală pentru gestionarea erorilor în Java.
try {
FileReader f = new FileReader("file.txt"); // may throw IOException
// ... use it ...
} catch (FileNotFoundException e) {
System.out.println("not found: " + e.getMessage()); // specific first
} catch (IOException e) {
System.out.println("io error"); // broader after
} finally {
System.out.println("always runs — cleanup"); // runs no matter what
}
finally se execută întotdeauna (curățare), chiar dacă o excepție este aruncată sau apare un return.
Throwable
├── Error — serious JVM problems (OutOfMemoryError) — don't catch
└── Exception
├── RuntimeException → UNCHECKED (not enforced by the compiler)
│ NullPointerException, IllegalArgumentException, IndexOutOfBounds...
└── (other Exceptions) → CHECKED (compiler enforces handling)
IOException, SQLException...
// MUST either catch it or declare `throws` — the compiler won't let you ignore it
public void readFile() throws IOException { // declare it
Files.readAllLines(Paths.get("file.txt")); // throws checked IOException
}
Checked exceptions (IOException, SQLException) reprezintă condiții recuperabile, așteptate (un fișier lipsă, o eșec de rețea). Compilatorul te forțează să le tratezi sau să le declari — făcând tratarea erorilor externe explicită.
// NOT required to declare or catch — usually indicate PROGRAMMING BUGS
String s = null;
s.length(); // NullPointerException (unchecked)
int x = arr[10]; // ArrayIndexOutOfBoundsException (unchecked)
Integer.parseInt("abc"); // NumberFormatException (unchecked)
Unchecked (subclase de RuntimeException) semnalizează de obicei erori de programare — corectezi bug-ul în loc să-l prindă peste tot. Compilatorul nu forțează tratarea.
// resources implementing AutoCloseable are closed automatically
try (FileReader f = new FileReader("file.txt")) {
// use f
} // f.close() called automatically, even on exception — no finally needed
✓ Catch specific exceptions, not bare Exception
✓ Use try-with-resources for files/connections (auto-close)
✓ Don't swallow exceptions silently (empty catch blocks)
✓ Throw meaningful exceptions; include context in messages
✓ Custom exceptions extend Exception (checked) or RuntimeException (unchecked)
Gestionarea robustă a erorilor este esențială, iar distincția checked/unchecked din Java este o caracteristică definitoriu (și dezbătută) care merită înțeleasă profund.
Checked exceptions forțează tratarea explicită a erorilor externe așteptate (I/O, DB) — promovând fiabilitate dar uneori criticată ca fiind verbală; unchecked exceptions reprezintă bug-uri de corectat în loc de a fi prinse în mod obișnuit.
Cunoașterea ierarhiei, când se aplică fiecare tip, semantica try/catch/finally și moderne try-with-resources pentru curățare automată este fundamentală pentru scrierea Java corect și fiabil — și pentru proiectarea excepțiilor proprii în mod adecvat.
Distincția determină modul în care API-urile Java sunt proiectate și este un subiect frecvent în interviuri și revizuiri de cod.