Hur fungerar undantagshantering och distinktionen mellan kontrollerad/okontrollerad?

Question

Accepted Answer

Java hanterar fel med **`try`/`catch`/`finally`** och skiljer på ett unikt sätt mellan **kontrollerade** undantag (måste deklareras eller hanteras) och **okontrollerade** undantag (körning, inte tvingade). Att förstå denna skillnad är central för felhantering i Java.

## Grundläggande 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` körs alltid (rensning), även om ett undantag kastas eller en `return` förekommer.

## Undantagshierarkin

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

## Kontrollerade undantag — kompilatorkrävd

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

**Kontrollerade** undantag (IOException, SQLException) representerar återhämtningsbara, förväntade förhållanden (en fil som saknas, ett nätverksfel). Kompilatorn *tvingar* dig att hantera eller deklarera dem — vilket gör extern felhantering explicit.

## Okontrollerade undantag — körning, inte tvingade

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

**Okontrollerade** (RuntimeException-underklasser) signalerar vanligtvis programmeringsfel — du åtgärdar buggen i stället för att fånga den överallt. Kompilatorn tvingar inte hantering.

## try-with-resources (automatisk rensning)

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

## Bästa praxis

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

## Varför det är viktigt

Robust felhantering är väsentlig, och Javas **distinktion mellan kontrollerade och okontrollerade undantag är en definierande (och debatterad) funktion** som är värd att förstå djupt.

Kontrollerade undantag tvingar explicit hantering av förväntade externa fel (I/O, DB) — främjar tillförlitlighet men kritiseras ibland som verbose; okontrollerade undantag representerar buggar att åtgärda i stället för att rutinmässigt fånga.

Att kunna hierarkin, när var typ gäller, semantiken för `try/catch/finally` och moderna **try-with-resources** för automatisk rensning är grundläggande för att skriva korrekt, tillförlitlig Java — och för att designa dina egna undantag på lämpligt sätt.

Skillnaden formar hur Java API:er designas och är ett vanligt samtalämne vid intervjuer och kodgranskning.