Panic et recover en Go : panics d'exécution et quand paniquer

À quoi ressemble un panic

Un panic arrête la fonction courante, exécute ses appels différés, puis fait de même dans son appelant, et ainsi de suite en remontant la pile. S'il atteint le sommet de la goroutine, le programme plante.

package main

import "fmt"

func main() {
	defer fmt.Println("deferred in main: still runs")

	nums := []int{1, 2, 3}
	i := 5
	fmt.Println("before")
	fmt.Println(nums[i]) // panics
	fmt.Println("never printed")
}

Ce programme sort avec le statut 2. La sortie est :

before
deferred in main: still runs
panic: runtime error: index out of range [5] with length 3

goroutine 1 [running]:
main.main()
	/tmp/main.go:11 +0x...
exit status 2

L'appel différé s'est exécuté avant le rapport de plantage. La trace nomme la goroutine, la fonction et la ligne, ce qui suffit généralement à trouver le bug.

Les panics d'exécution courants

Chacun de ces cas est un bug du programme, pas une condition à gérer. La correction est une vérification des bornes, un test de nil, un make ou une assertion comma-ok, pas un recover.

Récupérer

recover() arrête un panic. Il ne fonctionne que s'il est appelé directement dans une fonction différée, parce que les fonctions différées sont le seul code qui s'exécute pendant le déroulement d'un panic.

package main

import "fmt"

func safeDivide(a, b int) (result int, err error) {
	defer func() {
		if r := recover(); r != nil {
			err = fmt.Errorf("recovered: %v", r)
		}
	}()
	return a / b, nil
}

func main() {
	fmt.Println(safeDivide(10, 2))
	fmt.Println(safeDivide(1, 0))
	fmt.Println("program continues")
}

Sortie :

5 <nil>
0 recovered: runtime error: integer divide by zero
program continues

Ce qui s'est passé lors du second appel :

1. a / b a provoqué un panic.
2. La closure différée s'est exécutée, et recover() a renvoyé la valeur du panic (une runtime.Error).
3. Le déroulement s'est arrêté. safeDivide est retournée normalement à main, avec le résultat nommé err défini par la closure.

C'est le résultat nommé qui permet à la fonction différée de renvoyer une erreur. Sans lui, la fonction renvoie ses valeurs zéro. La page defer explique comment les closures différées modifient les résultats.

recover() renvoie nil en l'absence de panic, donc le test if r != nil rend la fonction différée inoffensive sur le chemin normal. Appelé hors d'une fonction différée, ou dans une fonction appelée par la fonction différée, recover renvoie nil et ne fait rien.

panic avec votre propre valeur

panic accepte n'importe quelle valeur. Une erreur ou une chaîne est typique.

package main

import (
	"errors"
	"fmt"
)

var ErrInvariant = errors.New("invariant violated")

func mustPositive(n int) int {
	if n <= 0 {
		panic(fmt.Errorf("mustPositive(%d): %w", n, ErrInvariant))
	}
	return n
}

func main() {
	defer func() {
		r := recover()
		if err, ok := r.(error); ok && errors.Is(err, ErrInvariant) {
			fmt.Println("caught:", err)
			return
		}
		if r != nil {
			panic(r) // not ours: re-panic
		}
	}()

	fmt.Println(mustPositive(3))
	fmt.Println(mustPositive(-1))
}

Récupérez ce que vous attendez et relancez le panic pour tout le reste. Avaler tous les panics masque de vrais bugs.

Depuis Go 1.21, panic(nil) est transformé en *runtime.PanicNilError, donc un recover() qui renvoie nil signifie désormais de façon fiable « pas de panic ».

Panics dans les goroutines

recover n'attrape que les panics de sa propre goroutine. Un panic dans n'importe quelle goroutine sans recover tue tout le processus, y compris main et toutes les autres goroutines.

package main

import (
	"fmt"
	"sync"
)

func safeGo(wg *sync.WaitGroup, name string, f func()) {
	wg.Add(1)
	go func() {
		defer wg.Done()
		defer func() {
			if r := recover(); r != nil {
				fmt.Printf("worker %s panicked: %v\n", name, r)
			}
		}()
		f()
	}()
}

func main() {
	var wg sync.WaitGroup
	safeGo(&wg, "ok", func() { fmt.Println("worker ok done") })
	safeGo(&wg, "bad", func() {
		var m map[string]int
		m["x"] = 1
	})
	wg.Wait()
	fmt.Println("main finished")
}

Les deux lignes des workers peuvent s'afficher dans n'importe quel ordre ; main finished vient toujours en dernier. Un defer recover() dans main n'aurait pas sauvé le programme du second worker. C'est pourquoi les serveurs HTTP récupèrent requête par requête : net/http récupère les panics dans la goroutine de chaque handler, les journalise et ferme cette connexion, pour qu'une mauvaise requête ne fasse pas tomber le serveur.

Certains échecs sont des erreurs fatales, pas des panics, et ne peuvent pas être récupérés du tout : concurrent map writes, le manque de mémoire, et le all goroutines are asleep du détecteur de deadlocks.

Quand paniquer est le bon choix

La règle générale de Go : renvoyez des erreurs pour tout ce qui peut mal tourner à l'exécution, et ne paniquez que pour les erreurs du programmeur. Concrètement, paniquer est approprié quand :

• Un invariant est cassé. Un switch sur votre propre enum atteint un cas qui ne peut pas se produire. Continuer corromprait des données.
• Un utilitaire Must reçoit une entrée constante invalide. regexp.MustCompile, template.Must et uuid.MustParse enveloppent une fonction qui renvoie une erreur et paniquent en cas d'échec. Utilisez-les pour des valeurs connues à la compilation, typiquement des variables au niveau du package, où un échec signifie que le code source est faux :

var emailRE = regexp.MustCompile(`^[^@\s]+@[^@\s]+$`)

• Le démarrage ne peut pas continuer. Une configuration obligatoire manque dans main. Même là, afficher l'erreur et appeler os.Exit(1) est souvent plus propre qu'une trace de pile.

Panic n'est pas le bon outil pour :

• Les échecs prévus : une saisie utilisateur invalide, un fichier manquant, un timeout. Renvoyez une error ; voir la gestion des erreurs.
• Le flux de contrôle : utiliser panic et recover comme des exceptions à travers un grand arbre d'appels rend le code difficile à suivre. La bibliothèque standard le fait en interne à quelques endroits (l'encodeur de encoding/json), en récupérant toujours avant de retourner, pour qu'aucun panic ne s'échappe du package.
• Les API de bibliothèque : une bibliothèque qui panique sur une entrée invalide oblige chaque appelant à ajouter des recover. Renvoyez une erreur.

Erreurs courantes

• Appeler recover hors d'une fonction différée. Il renvoie nil.
• Récupérer dans main le panic d'une goroutine. Chaque goroutine a besoin du sien.
• Avaler tous les panics. Journalisez avec la pile (debug.Stack() de runtime/debug) et relancez le panic pour ce que vous n'attendiez pas.
• Utiliser recover pour gérer des écritures dans une map nil ou des indices hors limites. Corrigez plutôt le bug.