Fehlerbehandlung in Go: Wrapping mit %w, errors.Is und errors.As

Worum es geht

In Go ist ein Fehler jeder Wert, dessen Typ eine Methode Error() string besitzt; Funktionen geben ihn als letztes Ergebnis zurück, und nil bedeutet Erfolg. Es gibt keine Exceptions: Die Go-FAQ erklärt das Design als Rückgabe mehrerer Werte für gewöhnliche Fehlschläge plus panic/recover für wirklich aussergewöhnliche Zustände. Seit Go 1.13 bilden Fehler eine Kette. fmt.Errorf("open config: %w", err) gibt einen Fehler zurück, der Unwrap() error implementiert, und die Dokumentation des Pakets errors beschreibt, wie errors.Is und errors.As diesen Baum durchlaufen (zuerst der Fehler selbst, dann seine Kinder, in Tiefensuche): Is vergleicht mit einem Zielwert, As findet den ersten Fehler, der einem Zieltyp zuweisbar ist, und kopiert ihn heraus. errors.Join (Go 1.20) und fmt.Errorf mit mehreren %w-Verben erzeugen Fehler, deren Unwrap []error zurückgibt. Go 1.26 fügt das generische errors.AsType[E](err) hinzu, das den typisierten Wert und einen Bool-Wert zurückgibt.

Warum es wichtig ist

Wer von Python oder JavaScript kommt, greift reflexartig zu try/except um einen Block; in Go entscheidet jede Aufrufstelle selbst. Zwei Gewohnheiten aus dynamischen Sprachen scheitern hier: der Vergleich von err.Error()-Strings, die sich ändern, sobald eine Schicht Kontext hinzufügt, und der Vergleich err == ErrNotFound mit ==, der versagt, sobald der Fehler gewrappt wurde. Die Dokumentation hält genau aus diesem Grund fest, dass errors.Is(err, fs.ErrExist) gegenüber err == fs.ErrExist vorzuziehen ist.

So wird es angewendet

• Sentinel-Fehler als Paketvariablen deklarieren (var ErrNotFound = errors.New("not found")) und strukturierte Fehler als Typen mit Feldern; Aufrufer gleichen mit errors.Is oder errors.As ab.
• Mit %w wrappen, wenn der Aufrufer sinnvollerweise die Ursache untersuchen können soll, und mit %v, wenn die Ursache ein Implementierungsdetail ist; der Go-Blog rät, einen Fehler zu wrappen, um ihn Aufrufern zugänglich zu machen, und nicht zu wrappen, wenn dies Implementierungsdetails offenlegen würde.
• Pro Schicht einmal Kontext in der Form "what was being done: %w" hinzufügen, kleingeschrieben und ohne abschliessende Interpunktion, damit sich Meldungen wie eine Kette von aussen nach innen lesen.
• Entweder behandeln oder zurückgeben, nicht beides: Einen Fehler zu loggen und ihn gleichzeitig zurückzugeben erzeugt auf jeder Ebene doppelte Logzeilen.
• Einem eigenen Typ eine Methode Is(error) bool geben, wenn er als gleich zu einem bestehenden Sentinel gelten soll; die Paketdokumentation beschreibt diesen Hook.

Stolpersteine

%v bricht die Kette stillschweigend ab. Das Wrappen eines nil-Fehlers erzeugt einen Fehler, der nicht nil ist. Eine Funktion, die einen typisierten Nil-Pointer als error zurückgibt, gibt ein Interface zurück, das nicht nil ist (siehe den Artikel zu Interfaces). sql.ErrNoRows über %w aus einem Repository zurückzugeben, bindet Aufrufer an das Datenbankpaket – genau das eigene Beispiel des Blogs. panic ist kein allgemeiner Fehlermechanismus; es bleibt Programmierfehlern vorbehalten, und recover erfolgt nur an Goroutine-Grenzen.