defer, panic & recover

defer agenda a limpeza na saída da função, panic inicia o desenrolar da pilha e recover pode interromper esse desenrolar - mas apenas dentro de uma chamada deferida.

Esses três mecanismos são a resposta do Go para a desmontagem estruturada sem exceções para erros normais.

Resumo

defer empilha chamadas em uma pilha LIFO por goroutine executada quando a função envolvente retorna.

Argumentos para funções deferidas são avaliados imediatamente, mas a chamada espera até o retorno.

panic executa chamadas deferidas enquanto procura por um recover.

recover retorna o valor do panic apenas durante esse desenrolar.

Falhas esperadas devem usar retornos error, não panic.

Receita

Cartão de receita de referência rápida - pronto para copiar e colar.

package main
 
import (
    "fmt"
    "os"
)
 
func readConfig(path string) (string, error) {
    f, err := os.Open(path)
    if err != nil {
        return "", err
    }
    // Agenda o fechamento do arquivo para quando a função readConfig retornar.
    defer f.Close()
 
    buf := make([]byte, 64)
    n, err := f.Read(buf)
    if err != nil {
        return "", err
    }
    return string(buf[:n]), nil
}
 
func main() {
    text, err := readConfig("config.txt")
    if err != nil {
        fmt.Println(err)
        return
    }
    fmt.Println(text)
}

Quando usar isso:

• Use defer imediatamente após a aquisição bem-sucedida de um recurso (Open, Lock, BeginTx).
• Use panic para estados impossíveis que indicam bugs do programador, não falhas de I/O.
• Use recover em limites de processo (middleware HTTP, nível superior de worker) para registrar e retornar 500.
• Retorne error para qualquer coisa que um chamador possa razoavelmente lidar ou tentar novamente.

Exemplo de Trabalho

package main
 
import (
    "fmt"
    "sync"
)
 
func worker(id int, wg *sync.WaitGroup) {
    // Agenda a decrementação do WaitGroup para quando a função worker retornar.
    defer wg.Done()
 
    // Agenda uma função anônima que tentará recuperar de um panic.
    defer func() {
        if r := recover(); r != nil {
            fmt.Printf("worker %d recovered: %v\n", id, r)
        }
    }()
 
    if id == 2 {
        // Simula um bug causando um panic.
        panic("simulated bug")
    }
    fmt.Println("worker", id, "ok")
}
 
func main() {
    var wg sync.WaitGroup
    for id := 1; id <= 3; id++ {
        wg.Add(1)
        go worker(id, &wg)
    }
    wg.Wait()
    fmt.Println("all workers finished")
}

O que isso demonstra:

• defer wg.Done() é executado mesmo quando panic ocorre mais tarde na função.
• O defer interno com recover captura o panic sem encerrar todo o programa.
• Outras goroutines continuam - panic é por goroutine, a menos que atinja main.
• Ordem: chamadas deferidas são executadas em LIFO antes que a função realmente retorne.

Mergulho Profundo

Como Funciona

• Cada goroutine mantém uma pilha de defer; o empilhamento ocorre no momento da execução da instrução defer.
• Argumentos de funções deferidas são avaliados na linha defer, não no momento do desenrolar (cuidado com variáveis de loop e ponteiros).
• Em caso de panic, o runtime executa as funções deferidas de dentro para fora até que recover pare a propagação ou a pilha termine.
• Se o panic não for recuperado, o programa imprime um rastreamento de pilha e sai (ou encerra a goroutine em workers).
• recover() fora de uma função deferida sempre retorna nil.

Linha do Tempo de defer / panic / recover

Notas do Go

// Resultado nomeado + defer pode ajustar valores de retorno
func divide(a, b int) (q int, err error) {
    // Agenda a verificação de divisão por zero.
    defer func() {
        if b == 0 {
            // Se b for zero, define o erro.
            err = fmt.Errorf("divide by zero")
        }
    }()
    // Cuidado: a divisão ainda pode causar panic por zero nesta forma ingênua.
    return a / b, nil
}
 
// Prefira verificação explícita antes da divisão em vez de confiar no panic

Armadilhas

• Defer em loops - for { defer f() } aumenta a pilha de defer até que a função retorne. Correção: envolva o corpo do loop em uma função aninhada ou use defer fora do loop principal.
• Capturando variáveis de loop em argumentos de defer - Argumentos são avaliados uma vez por instrução defer; closures em literais de função deferida veem os valores finais. Correção: passe valores como parâmetros: defer func(v int) { ... }(i).
• Recover fora de defer - recover() retorna nil e não para o panic. Correção: chame recover apenas dentro de defer func() { ... }().
• Engolindo todos os panics silenciosamente - Um recover vazio esconde bugs. Correção: registre a pilha, incremente métricas, retorne 500 para clientes.
• Usando panic para fluxo de controle - Torna as APIs difíceis de usar e testar. Correção: retorne error ou um resultado (T, bool).
• Custo do defer em loops apertados - Sobrecarga mensurável em benchmarks. Correção: mova o defer para a função externa ou use limpeza explícita quando comprovadamente for um gargalo.

Alternativas

FAQs

Relacionados

• Control Flow in HTTP Middleware - recover em limites de requisição
• Control Flow Basics - primeiros snippets de defer e recover
• Go Control Flow: Expression-Oriented Design - como defer se encaixa no fluxo orientado a expressões
• if with Initialization & switch Patterns - abre arquivos e depois defer close
• Control Flow Best Practices - quando não usar panic

Versões de Stack: Esta página foi escrita para Go 1.26.x (GC padrão Green Tea, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).