Warum Go die Fehlerbehandlung nicht vereinfachen wird

Vorwort

„Fehlerbehandlung in Go ist zu wortreich zum Schreiben.“ – Dies ist eine Ansicht, der fast jeder Go-Programmierer zustimmt.

Kürzlich hat das Go-Team einen offiziellen Blog-Beitrag veröffentlicht, in dem es formell ankündigt, dass es keine neuen Vorschläge für die Syntax der Fehlerbehandlung mehr verfolgen wird. Das bedeutet, dass Sie beim Schreiben von Go-Code auch in Zukunft häufig die vertraute Zeile if err != nil { return err } eintippen werden.

Dies ist nicht nur das Ende eines Vorschlags für syntaktischen Zucker – es ist eine Bestätigung der gesamten Philosophie hinter der Sprache. Warum hat das Go-Team diese Entscheidung getroffen? Und wie sollen wir ihre Beharrlichkeit interpretieren?

Drei Versuche, drei Misserfolge: Die Reise der Go-Syntax zur Fehlerbehandlung

In den letzten sieben Jahren hat das Go-Team dreimal versucht, das Problem der „sich wiederholenden Fehlerbehandlung“ durch die Einführung neuer Syntaxmechanismen anzugehen. Keine dieser Bemühungen wurde angenommen.

Der erste Versuch: Der check / handle-Vorschlag von 2018

Dieser Vorschlag stammte aus dem Go 2-Entwurf. Es war eine vollständige syntaktische Änderung, die darauf abzielte, Folgendes einzuführen:

• check() zum Erfassen von error aus Funktionsaufrufen;
• Ein handle-Block für die zentrale Fehlerbehandlung.

func printSum(a, b string) error {
    handle err { return err }         // All check failures jump here
    x := check(strconv.Atoi(a))
    y := check(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

• 🔍 Vorteile: Klare Struktur, einheitliche Fehlerpfadverwaltung.
• ⚠️ Nachteile: Führt neue Syntaxblöcke ein, erschwert die Lernkurve, erhöht die semantische Komplexität und löste weit verbreitete Kontroversen aus.

Am Ende kam das Go-Team zu dem Schluss, dass der Mechanismus zu kompliziert war, und er ging nie über das Entwurfsstadium hinaus.

Der zweite Versuch: Der try()-Vorschlag von 2019

Aus der ersten Runde lernend, schlug das Go-Team eine leichtere Version vor: die try()-Funktion.

func printSum(a, b string) error {
    x := try(strconv.Atoi(a))
    y := try(strconv.Atoi(b))
    fmt.Println("result:", x + y)
    return nil
}

Die im Wesentlichen Folgendem entspricht:

x, err := strconv.Atoi(a)
if err != nil {
    return err
}

• 🔍 Vorteile: Einfach, klar, führt keine neuen Syntaxblöcke ein – nur eine integrierte Funktion.
• ⚠️ Nachteile: Die automatische return-Anweisung verschleiert den Kontrollfluss und verstößt gegen die langjährige Betonung von Go auf „explizite Lesbarkeit“. Es erschwert das Debuggen und erhöht die kognitive Belastung.

Schließlich wurde dieser Vorschlag aufgrund starken Widerstands aus der Community offiziell verworfen.

Der dritte Versuch: Der ?-Operatorvorschlag von 2024

Diesmal lehnte sich das Go-Team an ein fundierteres Design an: Inspiriert von Rusts ? schlugen sie syntaktischen Postfix-Zucker für die Fehlerbehandlung vor:

func printSum(a, b string) error {
    x := strconv.Atoi(a) ?
    y := strconv.Atoi(b) ?
    fmt.Println("result:", x + y)
    return nil
}

Leider wurde auch dieser Vorschlag, wie die vorherigen, schnell von verschiedenen Kritikpunkten und einer Flut von auf persönlichen Vorlieben basierenden Optimierungen erstickt.

Die endgültige Entscheidung: Keine Änderungen mehr auf Syntaxebene

Alle drei Bemühungen scheiterten daran, einen breiten Konsens zu erzielen. Im Juni 2025 gab das Go-Team offiziell in seinem Blog bekannt:

„Für die absehbare Zukunft wird das Go-Team keine syntaktischen Sprachänderungen für die Fehlerbehandlung mehr verfolgen. Wir werden auch alle offenen und eingehenden Vorschläge, die sich primär mit der Syntax der Fehlerbehandlung befassen, ohne weitere Untersuchung schließen.“

Diese Entscheidung beruhte nicht auf einem Mangel an technischen Lösungen, sondern auf einer Kombination aus Konsenslücken, Kosten-Nutzen-Analysen und Sprachphilosophie.

Sie markiert nicht nur einen pragmatischen Abschluss, sondern eine Bestätigung der Designprinzipien von Go.

Warum hat das Go-Team an seinen Ansichten festgehalten? Zwei Kernbegründungen erklärt

Dem Go-Team ist die Tatsache nicht bewusst, dass die Fehlerbehandlung „sich wiederholend zu schreiben“ ist, und es ist nicht so, dass sie keine prägnantere Syntax finden konnten. In den letzten sieben Jahren haben sie persönlich drei Vorschläge eingebracht, nur um bei jedem den Stecker zu ziehen. Hier geht es nicht um technische Einschränkungen, sondern um Werturteile.

Wir können verstehen, warum sich das Go-Team letztendlich für „keine Änderungen“ entschieden hat, aus zwei Perspektiven:

1. Es wurde kein „überwältigender Konsens“ erzielt

Das Go-Team betonte wiederholt: „Wir suchen nicht nur nach einer funktionierenden Lösung, sondern nach einer, die allgemein akzeptiert und verwendet wird.