Hoe handelt Go fouten af als waarden?

Question

IT Interview Practice · Accepted Answer

Go heeft **geen uitzonderingen** voor normale fouten. In plaats daarvan zijn fouten **waarden** die door functies worden geretourneerd (meestal als de laatste retourwaarde), en roepende functies **controleren ze expliciet**. Dit maakt foutafhandeling zichtbaar, opzettelijk en onmogelijk om stilzwijgend te negeren — een bepaalde Go-filosofie.

## Het error-type en het basispatroon

```go
// `error` is a built-in interface: anything with an Error() string method
type error interface {
    Error() string
}

// functions return (result, error) — error is nil on success
func divide(a, b float64) (float64, error) {
    if b == 0 {
        return 0, errors.New("division by zero")   // create an error
    }
    return a / b, nil    // nil = no error
}

// the ubiquitous calling pattern
result, err := divide(10, 0)
if err != nil {              // CHECK the error explicitly
    fmt.Println("error:", err)
    return
}
fmt.Println(result)
```

De `if err != nil { ... }` controle komt voortdurend voor in Go — elke bewerking die kan mislukken, wordt gevolgd door een expliciete foutcontrole. Deze verbositeit is opzettelijk: fouten zijn altijd zichtbaar en worden op de oproepplaats afgehandeld.

## Fouten maken

```go
errors.New("something failed")                       // simple error
fmt.Errorf("failed to process %s: %w", name, err)    // formatted, with WRAPPING (%w)
```

## Fouten verpakken en inspecteren

```go
// %w WRAPS an underlying error, preserving the chain
if err != nil {
    return fmt.Errorf("reading config: %w", err)   // adds context, keeps original
}

// unwrap and inspect with errors.Is / errors.As
if errors.Is(err, os.ErrNotExist) { ... }          // check for a specific error
var pathErr *os.PathError
if errors.As(err, &pathErr) { ... }                 // extract a specific error type
```

Verpakking (`%w`) voegt context toe terwijl fouten omhoog propageren, terwijl `errors.Is`/`errors.As` je laten controleren op of specifieke onderliggende fouten extraheren — de moderne manier om foutketens af te handelen.

## Aangepaste fouttypen

```go
type ValidationError struct {
    Field string
}
func (e *ValidationError) Error() string {           // implement the error interface
    return "invalid field: " + e.Field
}
return &ValidationError{Field: "email"}
```

## errors vs panic

```text
error (values) → EXPECTED, recoverable conditions (file missing, bad input) — the norm
panic          → UNEXPECTED, programmer errors / unrecoverable (nil deref, out of bounds)
→ Use errors for normal failure handling; reserve panic for truly exceptional cases.
```

## Waarom het belangrijk is

Go's benadering van fout-als-waarde is een van de meest bepaalde en betwiste kenmerken, fundamenteel anders dan op uitzonderingen gebaseerde talen.

Door fouten als waarden terug te geven die roepende functies expliciet moeten controleren (`if err != nil`), maakt Go foutafhandeling **zichtbaar, lokaal en onmogelijk om per ongeluk te negeren** — je ziet precies waar elke fout wordt afgehandeld, wat de betrouwbaarheid verbetert ten koste van verbositeit.

Inzicht in deze filosofie, het `(result, error)` patroon, foutverpakking (`%w`) met `errors.Is`/`errors.As` voor het toevoegen van context en inspecteren van ketens, aangepaste fouttypen, en het onderscheid tussen fouten (normaal, herstelbaarheid) en panic (uitzonderlijk, programmeerfouten) is absoluut essentieel — het doordringt elk Go-programma en vertegenwoordigt een kernverschuiving in het denken voor ontwikkelaars afkomstig van op uitzonderingen gebaseerde talen.

Het is ook een van de meest voorkomende Go interview-onderwerpen.

Het error-type en het basispatroon

Fouten maken

Fouten verpakken en inspecteren

Aangepaste fouttypen

errors vs panic

Waarom het belangrijk is

Gerelateerde vragen