Golang Type Assertion: x.(T), Comma-ok und Type Switch

x.(T): den Wert aus einem Interface holen

Ein Interface-Wert verbirgt den konkreten Typ, den er enthält. Eine Type Assertion x.(T) fragt ihn zurück ab.

package main

import "fmt"

func main() {
	var v any = "gopher"

	s := v.(string) // v holds a string: ok
	fmt.Println(s, len(s))

	n, ok := v.(int) // comma-ok: no panic on mismatch
	fmt.Println(n, ok)

	if str, ok := v.(string); ok {
		fmt.Println("string of length", len(str))
	}
}

Ausgabe:

gopher 6
0 false
string of length 6

x muss einen Interface-Typ haben. Eine Assertion auf einen konkreten Typ kompiliert nicht: invalid operation: s (variable of type string) is not an interface.

Die Form mit einem Wert löst eine Panic aus

Ist die Assertion falsch, löst die Form mit einem Wert eine Panic mit einer Meldung aus, die beide Typen nennt:

package main

import "fmt"

func main() {
	defer func() {
		fmt.Println("recovered:", recover())
	}()

	var v any = 42
	s := v.(string)
	fmt.Println(s)
}

Ausgabe:

recovered: interface conversion: interface {} is int, not string

Nutz die Form mit einem Wert nur, wenn ein anderer Typ ein Programmierfehler wäre, bei dem das Programm abstürzen soll. Überall sonst nimmst du Comma-ok. Bei einem Fehlschlag liefert Comma-ok den Nullwert von T und false.

Auch eine Assertion auf ein nil-Interface schlägt fehl: var v any; v.(string) löst eine Panic mit interface conversion: interface {} is nil, not string aus, und die Comma-ok-Form liefert "", false.

Assertion auf ein anderes Interface

T kann ein Interface-Typ sein. Dann gelingt die Assertion, wenn der dynamische Wert T implementiert, und das Ergebnis behält denselben dynamischen Wert. So prüft die Standardbibliothek optionale Fähigkeiten.

package main

import (
	"fmt"
	"strings"
)

type Temp float64

func (t Temp) String() string { return fmt.Sprintf("%.1f degrees", float64(t)) }

func describe(v any) string {
	if s, ok := v.(fmt.Stringer); ok {
		return "Stringer: " + s.String()
	}
	return fmt.Sprintf("plain value: %v", v)
}

func main() {
	fmt.Println(describe(Temp(21.5)))
	fmt.Println(describe(42))

	// io.Copy uses the same trick to check for WriterTo / ReaderFrom.
	var r any = strings.NewReader("x")
	_, hasLen := r.(interface{ Len() int })
	fmt.Println("has Len:", hasLen)
}

io.Copy prüft, ob seine Quelle io.WriterTo implementiert, und nutzt das dann. fmt prüft auf Stringer und error. Mit diesem Muster bleibt ein kleines Interface klein, und Aufrufer profitieren trotzdem von reichhaltigeren Implementierungen.

Type Switch

Kann ein Wert einer von mehreren Typen sein, ersetzt ein Type Switch eine Kette von Assertions. x.(type) ist nur innerhalb eines switch gültig.

package main

import (
	"fmt"
	"strconv"
)

func toString(v any) string {
	switch x := v.(type) {
	case nil:
		return "nil"
	case string:
		return x // x is a string here
	case int, int64:
		return fmt.Sprintf("integer %v", x) // x is any: two types in one case
	case float64:
		return strconv.FormatFloat(x, 'f', 2, 64)
	case fmt.Stringer:
		return x.String()
	case error:
		return "error: " + x.Error()
	default:
		return fmt.Sprintf("unhandled %T", x)
	}
}

func main() {
	values := []any{"hi", 7, int64(8), 3.14159, nil, fmt.Errorf("boom"), []int{1}}
	for _, v := range values {
		fmt.Println(toString(v))
	}
}

Ausgabe:

hi
integer 7
integer 8
3.14
nil
error: boom
unhandled []int

Regeln, die du kennen solltest:

• In einem Case mit einem Typ hat x diesen Typ. In einem Case mit mehreren Typen und in default hat x den Typ des ursprünglichen Interface (hier any).
• Die Cases werden der Reihe nach geprüft. Setz spezifischere Interfaces vor allgemeinere, da ein Wert mehrere erfüllen kann.
• case nil passt nur auf ein nil-Interface, nicht auf ein Interface, das einen nil-Pointer enthält.
• In einem Type Switch gibt es kein fallthrough.

errors.As: die Assertion für gewrappte Fehler

Fehler werden oft mit Kontext gewrappt: fmt.Errorf("load config: %w", err). Eine direkte Type Assertion betrachtet nur den äußersten Fehler und übersieht den darin. errors.As läuft die Kette entlang.

package main

import (
	"errors"
	"fmt"
	"io/fs"
	"os"
)

func load() error {
	_, err := os.Open("/no/such/file")
	if err != nil {
		return fmt.Errorf("load config: %w", err)
	}
	return nil
}

func main() {
	err := load()

	_, ok := err.(*fs.PathError)
	fmt.Println("type assertion finds it:", ok)

	var pe *fs.PathError
	if errors.As(err, &pe) {
		fmt.Println("errors.As finds it:", pe.Op, pe.Path)
	}
}

Ausgabe:

type assertion finds it: false
errors.As finds it: open /no/such/file

Nutz eine Type Assertion auf Fehler nur, wenn du weißt, dass der Fehler nicht gewrappt ist, und das ist in der Praxis fast nie der Fall. Die Seite zu eigenen Fehlertypen behandelt errors.As, errors.Is und das Definieren eigener Fehlertypen.

Assertions vs Konvertierungen vs Generics

Code voller any und Type Switches ist oft ein Zeichen, dass Generics oder ein richtiges Interface die Absicht besser ausdrücken und Fehler schon beim Kompilieren finden würden.

Häufige Fehler

• Die Panic-Form auf nicht vertrauenswürdigen Daten. Dekodiertes JSON, Map-Werte vom Typ any, Plugin-Eingaben: immer Comma-ok.
• Assertion auf den falschen Zahlentyp. JSON-Zahlen werden in any als float64 dekodiert, also schlägt v.(int) bei ihnen fehl.
• Assertion auf einen Werttyp, wenn ein Pointer gespeichert ist. Enthält das Interface *User, schlägt v.(User) fehl. Nimm v.(*User).
• Type Assertions auf Fehler. Nimm errors.As.