ProgrammatieBackend ontwikkelaar

Leg uit hoe typechecking en typevorming werkt in Go. Wat voor soort typeconversies bestaan er en wat zijn de verschillen?

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord

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:

  1. Expliciete typeconversie (Type Casting) – wanneer de programmeur expliciet het gewenste type aangeeft.
  2. Assertion (type assertion) – toegepast op interfaces om te controleren op een specifiek onderliggend type.

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).

Vraag met een valstrik

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") }

Voorbeelden van echte fouten vanwege onwetendheid over de nuances van het onderwerp


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.