Comment Go gère-t-il les erreurs en tant que valeurs ?

Question

Accepted Answer

Go n'a **pas d'exceptions** pour les erreurs ordinaires. Au lieu de cela, les erreurs sont des **valeurs** retournées par les fonctions (généralement en tant que dernière valeur de retour), et les appelants les **vérifient explicitement**. Cela rend la gestion des erreurs visible, délibérée et impossible à ignorer silencieusement — une philosophie fondamentale de Go.

## Pourquoi c'est important

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

La vérification `if err != nil { ... }` apparaît constamment en Go — chaque opération défaillante est suivie d'une vérification d'erreur explicite. Cette verbosité est délibérée : les erreurs sont toujours visibles et gérées au site d'appel.

## Créer des erreurs

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

## Enrober et inspecter les erreurs

```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
```

L'enrobage (`%w`) ajoute du contexte à mesure que les erreurs se propagent vers le haut, tandis que `errors.Is`/`errors.As` vous permettent de vérifier ou d'extraire des erreurs sous-jacentes spécifiques — la façon moderne de gérer les chaînes d'erreurs.

## Types d'erreurs personnalisés

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

L'approche de Go qui traite les erreurs comme des valeurs est l'une de ses caractéristiques les plus définissantes et débattues, fondamentalement différente des langages basés sur les exceptions.

En retournant les erreurs comme des valeurs que les appelants doivent vérifier explicitement (`if err != nil`), Go rend la gestion des erreurs **visible, locale et impossible à ignorer accidentellement** — vous voyez exactement où chaque erreur est gérée, améliorant la fiabilité au prix de la verbosité.

Comprendre cette philosophie, le modèle `(result, error)`, l'enrobage d'erreurs (`%w`) avec `errors.Is`/`errors.As` pour ajouter du contexte et inspecter les chaînes, les types d'erreurs personnalisés, et la distinction entre les erreurs (normales, récupérables) et panic (exceptionnelles, erreurs de programmeur) est absolument essentiel — cela imprègne chaque programme Go et représente un changement mental fondamental pour les développeurs venant de langages basés sur les exceptions.

C'est aussi l'un des sujets d'entretien Go les plus courants.