Fehlerbehandlung in Go: Ein kritischer Blick auf Schnittstellen und Fehlertypen

Fehlerbehandlung in Go: Ein kritischer Blick auf Schnittstellen und Fehlertypen

In der Go-Programmierung ist die Fehlerbehandlung ein zentrales Thema, das jedoch oft zu subtilen Fehlern führen kann – insbesondere, wenn Entwickler:innen konkrete Fehlertypen anstelle des error-Interfaces verwenden. Dieser Artikel beleuchtet eine häufige Fehlerquelle und erklärt, warum der richtige Umgang mit Fehlern mehr als nur technisches Know-how erfordert.

Das Problem konkreter Fehlertypen

Betrachten wir dieses Codebeispiel:

type myError struct{}

func (c *myError) Error() string {
    return "Unexpected Error."
}

func run() ([]byte, *myError) {
    return nil, nil
}

func main() {
    var err error
    if _, err = run(); err != nil {
        log.Fatal("We are failed")
    }
    log.Println("Everything is OK")
}

Ausgabe:

We are failed

Warum passiert das?

• Die Funktion run() gibt *myError als konkreten Typ zurück, nicht das error-Interface.
• Ein nil-Pointer vom Typ *myError ist nicht dasselbe wie ein nil-Wert des error-Interfaces.
• Die Zuweisung err = run() speichert einen nil-Pointer in einer Interface-Variable, wodurch err != nil gilt.

Die Lösung:
✔️ Immer das error-Interface als Rückgabetyp verwenden:

func run() ([]byte, error) { ... }

-

Fehlerbehandlung: Mehr als nur Technik

Fehlerbehandlung umfasst drei Schlüsselprinzipien:

1. Fehlererkennung: Wann soll ein Fehler die Ausführung stoppen?
2. Kontextprotokollierung: Welche Informationen sind für Debugging nötig?
3. Entscheidungsfindung: Kann das Programm fortgesetzt werden, oder muss es abbrechen?

Ein häufiges Problem ist die unvollständige Weitergabe von Kontext. Wenn eine Funktion einen Fehler nicht selbst behandeln kann, muss sie ihn mit ausreichenden Metadaten an höhere Ebenen weiterreichen.

-

Fehler wrappen: Standardbibliothek vs. Drittpakete

Option 1: Dave Cheney’s errors-Paket

import "github.com/pkg/errors"

func first(i int) error {
    if err := second(i); err != nil {
        return errors.Wrapf(err, "secondCall(%d)", i)
    }
    return nil
}

func second(i int) error {
    return &MainError{99}
}

Vorteile:

• Wrapf fügt Kontext hinzu.
• Cause extrahiert den ursprünglichen Fehler:

switch v := errors.Cause(err).(type) {
case *MainError:
    fmt.Println("Custom Error:", v.State)
}

Option 2: Standardbibliothek (errors und fmt)

Ohne externe Pakete lässt sich ähnliche Funktionalität mit fmt.Errorf und %w erreichen:

return fmt.Errorf("secondCall(%d): %w", i, err)

Extrahieren des Ursprungsfehlers:

func Cause(err error) error {
    root := err
    for {
        if err = errors.Unwrap(root); err == nil {
            return root
        }
        root = err
    }
}

-

Best Practices für robuste Fehlerbehandlung

1. Interface über Typen:
   Nie konkrete Fehlertypen zurückgeben – immer error verwenden.
2. Kontext ist König:
   Jeder Fehler sollte genug Informationen enthalten, um seinen Ursprung nachzuvollziehen.
3. Einheitliche Strategie:
   Im Team entscheiden: Nutzung der Standardbibliothek oder etablierter Pakete wie github.com/pkg/errors.
4. Logging mit Struktur:
   Fehlerprotokolle sollten Stacktraces, Metadaten (z.B. User-ID) und Severity-Levels enthalten.

-

Fazit

Die Verwendung konkreter Fehlertypen statt des error-Interfaces ist ein klassischer Anfängerfehler in Go, der zu schwer auffindbaren Bugs führt. Durch das Wrappen von Fehlern und eine konsistente Fehlerstrategie lässt sich jedoch nicht nur Code-Robustheit erreichen, sondern auch die Wartbarkeit deutlich verbessern.

Merksatz:

"Handle errors like you’re debugging at 3 AM – provide enough context to make sense of them when you’re half asleep."