panic e recover em Go: panics em tempo de execução e quando usar panic

Como é um panic

Um panic interrompe a função atual, executa as suas chamadas adiadas e depois faz o mesmo em quem a chamou, e assim por diante subindo a pilha. Se ele chegar ao topo da goroutine, o programa cai.

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

Este programa sai com status 2. A saída é:

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

A chamada adiada executou antes do relatório de falha. O trace informa a goroutine, a função e a linha, o que normalmente basta para encontrar o bug.

Panics comuns em tempo de execução

Cada um deles é um bug no programa, não uma condição a tratar. A correção é uma verificação de limites, uma verificação de nil, um make ou uma assertion vírgula-ok, não um recover.

Recuperando

recover() interrompe um panic. Ele só funciona quando chamado diretamente dentro de uma função adiada, porque funções adiadas são o único código que executa enquanto um panic desenrola a pilha.

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

Saída:

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

O que aconteceu na segunda chamada:

1. a / b causou panic.
2. A closure adiada executou, e recover() devolveu o valor do panic (um runtime.Error).
3. O desenrolar parou. safeDivide retornou normalmente para o main, com o resultado nomeado err definido pela closure.

O resultado nomeado é o que permite à função adiada devolver um erro. Sem ele, a função devolve os seus valores zero. A página de defer mostra como closures adiadas modificam resultados.

recover() devolve nil quando não há panic, então a verificação if r != nil torna a função adiada inofensiva no caminho normal. Chamado fora de uma função adiada, ou em uma função chamada pela função adiada, recover devolve nil e não faz nada.

panic com o seu próprio valor

panic aceita qualquer valor. Um erro ou uma string é o típico.

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

Recupere o que você espera e cause panic de novo em todo o resto. Engolir todo panic esconde bugs reais.

Desde o Go 1.21, panic(nil) é transformado em um *runtime.PanicNilError, então recover() devolver nil agora significa com certeza "não houve panic".

Panics em goroutines

O recover só captura panics na própria goroutine. Um panic em qualquer goroutine sem recover mata o processo inteiro, incluindo o main e todas as outras 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")
}

As duas linhas dos workers podem sair em qualquer ordem; main finished sempre vem por último. Um defer recover() no main não teria salvado o programa do segundo worker. É por isso que servidores HTTP recuperam por requisição: o net/http recupera panics na goroutine de cada handler, registra em log e fecha aquela conexão, para que uma requisição ruim não derrube o servidor.

Algumas falhas são erros fatais, não panics, e não podem ser recuperadas de jeito nenhum: concurrent map writes, falta de memória e o all goroutines are asleep do detector de deadlock.

Quando causar panic é a decisão certa

A regra geral do Go: devolva erros para tudo o que pode dar errado em tempo de execução, e cause panic só por erros do programador. Na prática, panic é apropriado quando:

• Uma invariante é quebrada. Um switch sobre o seu próprio enum chega a um case que não pode acontecer. Continuar corromperia dados.
• Um helper Must recebe uma entrada constante inválida. regexp.MustCompile, template.Must e uuid.MustParse envolvem uma função que devolve erro e causam panic em caso de falha. Use-os para valores conhecidos em tempo de compilação, normalmente variáveis de nível de pacote, em que uma falha significa que o código-fonte está errado:

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

• A inicialização não pode continuar. Falta uma configuração obrigatória no main. Mesmo aqui, imprimir o erro e chamar os.Exit(1) costuma ser mais limpo que um stack trace.

Panic é a ferramenta errada para:

• Falhas esperadas: entrada inválida do usuário, um arquivo ausente, um timeout. Devolva um error; veja tratamento de erros.
• Controle de fluxo: usar panic e recover como exceções em uma árvore de chamadas grande deixa o código difícil de acompanhar. A biblioteca padrão faz isso internamente em alguns lugares (o encoder do encoding/json), sempre recuperando antes de retornar, para que nenhum panic escape do pacote.
• APIs de bibliotecas: uma biblioteca que causa panic com entrada inválida obriga todo código que a chama a acrescentar recovers. Devolva um erro.

Erros comuns

• Chamar recover fora de uma função adiada. Ele devolve nil.
• Recuperar no main o panic de uma goroutine. Cada goroutine precisa do seu.
• Engolir todos os panics. Registre com a pilha (debug.Stack() de runtime/debug) e cause panic de novo no que você não esperava.
• Usar recover para lidar com escritas em map nil ou índices fora da faixa. Corrija o bug.