Hvordan fungerer undtagelseshåndtering og sondringen mellem kontrollerede og ukontrollerede undtagelser?

Question

Accepted Answer

Java håndterer fejl med **`try`/`catch`/`finally`** og skelner unikt mellem **kontrollerede** undtagelser (skal deklareres eller håndteres) og **ukontrollerede** undtagelser (runtime, ikke tvunget). At forstå denne forskel er centralt for fejlhåndtering i Java.

## Den grundlæggende struktur

```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` udføres altid (oprydning), selvom en undtagelse kastes eller et `return` sker.

## Undtagelseshierarkiet

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

## Kontrollerede undtagelser — tvunget af kompileren

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

**Kontrollerede** undtagelser (IOException, SQLException) repræsenterer genvindelige, forventede tilstande (en manglende fil, en netværksfejl). Kompileren *tvinger* dig til at håndtere eller deklarere dem — hvilket gør håndtering af eksterne fejl eksplicit.

## Ukontrollerede undtagelser — runtime, ikke tvunget

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

**Ukontrollerede** (RuntimeException-underklasser) signalerer typisk programmeringsfejl — du retter fejlen i stedet for at fange den overalt. Kompileren tvinger ikke håndtering.

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

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

## Bedste praksis

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

## Hvorfor det betyder noget

Robust fejlhåndtering er essentiel, og Javas **sondring mellem kontrollerede og ukontrollerede er en karakteristisk (og debateret) funktion** der er værd at forstå dybt.

Kontrollerede undtagelser tvinger eksplicit håndtering af forventede eksterne fejl (I/O, DB) — fremmer pålidelighed men kritiseres nogle gange for at være ordrig; ukontrollerede undtagelser repræsenterer fejl at rette i stedet for rutinemæssigt at fange.

At kende hierarkiet, hvornår hver type gælder, `try/catch/finally` semantikken og moderne **try-with-resources** til automatisk oprydning er fundamentalt for at skrive korrekt, pålidelig Java — og for at designe dine egne undtagelser passende.

Sondringen formes hvordan Java API'er er designet og er et hyppigt emne i interviews og code-reviews.