Panic e recover in Go: panic a runtime e quando usarli

Com'è fatto un panic

Un panic ferma la funzione corrente, esegue le sue chiamate in defer, poi fa lo stesso in chi l'ha chiamata, e così via risalendo lo stack. Se arriva in cima alla goroutine, il programma crasha.

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

Questo programma termina con stato 2. L'output è:

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

La chiamata in defer è stata eseguita prima del report del crash. Il trace indica la goroutine, la funzione e la riga, che di solito basta per trovare il bug.

I panic di runtime più comuni

Ognuno di questi è un bug nel programma, non una condizione da gestire. La soluzione è un controllo dei limiti, un controllo su nil, un make o una assertion comma-ok, non un recover.

Recuperare

recover() ferma un panic. Funziona solo quando viene chiamato direttamente dentro una funzione in defer, perché le funzioni in defer sono l'unico codice che gira mentre un panic risale lo stack.

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

Output:

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

Cosa è successo nella seconda chiamata:

1. a / b è andato in panic.
2. La closure in defer è stata eseguita, e recover() ha restituito il valore del panic (un runtime.Error).
3. La risalita si è fermata. safeDivide è tornata normalmente a main, con il risultato con nome err impostato dalla closure.

È il risultato con nome che permette alla funzione in defer di restituire un errore. Senza, la funzione restituisce i suoi zero value. La pagina su defer spiega come le closure in defer modificano i risultati.

recover() restituisce nil quando non c'è nessun panic, quindi il controllo if r != nil rende innocua la funzione in defer nel percorso normale. Chiamato fuori da una funzione in defer, o in una funzione chiamata dalla funzione in defer, recover restituisce nil e non fa niente.

panic con un tuo valore

panic accetta qualsiasi valore. Un errore o una stringa sono i casi tipici.

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

Recupera ciò che ti aspetti e rilancia il panic per tutto il resto. Inghiottire ogni panic nasconde bug reali.

Da Go 1.21, panic(nil) viene trasformato in un *runtime.PanicNilError, quindi un recover() che restituisce nil ora significa in modo affidabile "nessun panic".

Panic nelle goroutine

recover cattura solo i panic della propria goroutine. Un panic in qualsiasi goroutine senza recover uccide l'intero processo, compresi main e ogni altra goroutine.

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

Le due righe dei worker possono comparire in qualsiasi ordine; main finished arriva sempre per ultima. Un defer recover() in main non avrebbe salvato il programma dal secondo worker. Per questo i server HTTP fanno recover per ogni richiesta: net/http recupera i panic nella goroutine di ogni handler, li registra nel log e chiude quella connessione, così una richiesta sbagliata non butta giù il server.

Alcuni fallimenti sono errori fatali, non panic, e non si possono recuperare in nessun modo: concurrent map writes, la memoria esaurita e il messaggio all goroutines are asleep del rilevatore di deadlock.

Quando andare in panic è la scelta giusta

La regola generale di Go: restituisci errori per tutto ciò che può andare storto a runtime, e vai in panic solo per gli errori di chi programma. In concreto, il panic è appropriato quando:

• Un invariante è rotto. Uno switch sul tuo enum raggiunge un caso che non può succedere. Continuare corromperebbe i dati.
• Un helper Must riceve un input costante sbagliato. regexp.MustCompile, template.Must e uuid.MustParse avvolgono una funzione che restituisce un errore e vanno in panic in caso di fallimento. Usali per valori noti in fase di compilazione, tipicamente variabili a livello di package, dove un fallimento significa che il codice sorgente è sbagliato:

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

• L'avvio non può proseguire. Manca una configurazione obbligatoria in main. Anche qui, stampare l'errore e chiamare os.Exit(1) è spesso più pulito di uno stack trace.

Il panic è lo strumento sbagliato per:

• Fallimenti previsti: input non valido dell'utente, un file mancante, un timeout. Restituisci un error; vedi gestione degli errori.
• Controllo del flusso: usare panic e recover come eccezioni attraverso un grande albero di chiamate rende il codice difficile da seguire. La libreria standard lo fa internamente in un paio di punti (l'encoder di encoding/json), recuperando sempre prima di restituire, così nessun panic esce dal package.
• API di libreria: una libreria che va in panic con un input sbagliato costringe ogni chiamante ad aggiungere dei recover. Restituisci un errore.

Errori comuni

• Chiamare recover fuori da una funzione in defer. Restituisce nil.
• Fare recover in main per il panic di una goroutine. Ogni goroutine ha bisogno del suo.
• Inghiottire tutti i panic. Registra nel log con lo stack (debug.Stack() da runtime/debug) e rilancia il panic per ciò che non ti aspettavi.
• Usare recover per gestire scritture in map nil o indici fuori range. Correggi invece il bug.