Come funziona la gestione delle eccezioni e la distinzione tra checked/unchecked?

Question

Accepted Answer

Java gestisce gli errori con **`try`/`catch`/`finally`** e distingue univocamente le eccezioni **checked** (devono essere dichiarate o gestite) dalle eccezioni **unchecked** (runtime, non forzate). Comprendere questa distinzione è centrale nella gestione degli errori in Java.

## La struttura di base

```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` viene sempre eseguito (cleanup), anche se viene lanciata un'eccezione o si verifica un `return`.

## La gerarchia delle eccezioni

```text
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...
```

## Eccezioni checked — forzate dal compilatore

```java
// 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
}
```

Le eccezioni **checked** (IOException, SQLException) rappresentano condizioni recuperabili e previste (un file mancante, un guasto di rete). Il compilatore *ti forza* a gestirle o dichiararle — rendendo esplicita la gestione dei fallimenti esterni.

## Eccezioni unchecked — runtime, non forzate

```java
// 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)
```

Le eccezioni **unchecked** (sottoclassi di RuntimeException) solitamente segnalano errori di programmazione — correggi il bug piuttosto che catturarle ovunque. Il compilatore non forza la gestione.

## try-with-resources (auto-cleanup)

```java
// 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
```

## Best practices

```text
✓ 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)
```

## Perché è importante

La gestione robusta degli errori è essenziale, e la **distinzione checked/unchecked di Java è una caratteristica definitoria (e dibattuta)** che vale la pena approfondire.

Le eccezioni checked forzano la gestione esplicita dei fallimenti esterni previsti (I/O, DB) — promuovendo l'affidabilità ma a volte criticate per essere verbose; le eccezioni unchecked rappresentano bug da correggere piuttosto che catturare sistematicamente.

Conoscere la gerarchia, quando ogni tipo si applica, la semantica di `try/catch/finally` e il moderno **try-with-resources** per la pulizia automatica è fondamentale per scrivere Java corretto e affidabile — e per progettare le proprie eccezioni appropriatamente.

La distinzione plasma il modo in cui le API Java sono progettate ed è un argomento frequente in interviste e code review.