In de programmeertaal Go is er een statische strikte typechecking geïmplementeerd. Dit betekent dat het type van elke variabele bekend is tijdens de compilatie, en de compiler staat geen operaties toe met incompatibele types.
Er zijn twee soorten typeconversies:
Voorbeeld van expliciete typeconversie:
var i int = 42 var f float64 = float64(i)
Voorbeeld van type assertion:
var i interface{} = "hello" s, ok := i.(string) if ok { fmt.Println("String value:", s) } else { fmt.Println("i is geen string") }
Conversie is alleen mogelijk tussen compatibele basistypen (int → float64, rune → int32, maar string → int — niet mogelijk).
Kan interface{} een nil-waarde opslaan, en hoe controleer je correct of een variabele van het interface-type werkelijk nil is?
Een veelgemaakte fout is om de interface die een nil-waarde bevat, direct met nil te vergelijken:
var err error = nil var i interface{} = err fmt.Println(i == nil) // Verwachten true, maar het zal false zijn!
De juiste manier:
Controleer of zowel de interface zelf nil is, als de ingesloten waarde nil:
if i == nil || reflect.ValueOf(i).IsNil() { fmt.Println("i is daadwerkelijk nil") }
Verhaal
In een backendproject probeerde een ontwikkelaar verschillende fouten te verwerken via interface{}, vergeleek ze met nil. Hierdoor kon de fout niet correct worden gedetecteerd — er ontstonden verborgen bugs en verkeerde logica bij het retourneren van fouten aan de client.
Verhaal
Migratie tussen float64 en int zonder expliciete cast veroorzaakte stille dataverlies: waarden werden afgerond of incorrect omgezet, omdat de Go-compiler expliciete conversie vereist voor dergelijke operaties.
Verhaal
Bij het deserialiseren van interface-waarden bij het werken met map[string]interface{} (bijvoorbeeld uit JSON) leidden onverwachte getal typen (float64) tot paniek bij het gebruik van type assertion zonder aanvullende controle ok — de service viel om vanwege runtime error.