Fazendo as pazes com os Erros (Por que o if err != nil é meu amigo)

O choque das exceções

Em linguagens que usei antes de descobrir Go, o mecanismo try / catch parecia aquele barista que tenta “consertar” um café derramado sem avisar ao cliente: a exceção surge em outro ponto da fila, muitas vezes muito depois de o problema ter ocorrido. O código continua a fluir, mas o erro fica oculto, pronto para transbordar como espuma que sobe inesperadamente. Essa falta de rastreabilidade costuma transformar pequenos incidentes em catástrofes dignas de um “café queimado” servido a quem não pediu.

2. Erros são valores

Go adota uma postura mais honesta: o erro não é um evento cataclísmico que interrompe o universo, mas um valor que acompanha o resultado da função, tal como um bilhete ao lado do copo indicando “café frio” ou “sem açúcar”. Essa escolha faz com que o tratamento de falhas seja tão natural quanto checar se a água está quente antes de preparar o espresso.

dados, err := os.ReadFile("config.json")

Se err for nil, o café está perfeito; se não, o bilhete descreve o que deu errado. Não há “lançamento” de exceções que escapam da vista; tudo permanece visível no mesmo escopo.

3. A anatomia do if err != nil

O padrão idiomático

if err != nil { // tratar o erro }

é o equivalente a verificar a espuma antes de servir a bebida. Pode parecer repetitivo, quase como perguntar “já provou o café?” a cada gole, mas força o programador a considerar o “pior cenário” imediatamente após cada operação. Essa disciplina preventiva impede que um copo vazio chegue ao cliente, garantindo que cada passo do pipeline seja validado.

4. Exemplo prático (versão Go 1.16+)

package main import ( "fmt" "log" "os" ) // lerReceita abre e lê o conteúdo de um arquivo. // Cada operação potencialmente falível tem seu próprio cheque de qualidade. func lerReceita(caminho string) ([]byte, error) { // 1️⃣ Ler o arquivo em uma única chamada, o espresso direto da cápsula. conteudo, err := os.ReadFile(caminho) if err != nil { // Envolvemos o erro original (%w) para preservar a cadeia de causas. return nil, fmt.Errorf("não foi possível ler %s: %w", caminho, err) } // Tudo correu bem; devolvemos o conteúdo. return conteudo, nil } func main() { // 2️⃣ Solicitar a receita, aqui verificamos o resultado imediatamente. receita, err := lerReceita("receita.txt") if err != nil { // Decidimos se servimos um substituto ou avisamos o cliente. log.Fatalf("Falha ao carregar a receita: %v", err) } fmt.Println("Receita carregada:", string(receita)) }

Pontos de destaque

• os.ReadFile substitui o antigo ioutil.ReadFile, alinhando‑nos com as práticas recomendadas a partir do Go 1.16.
• %w em fmt.Errorf permite wrapping de erros, facilitando a inspeção posterior com errors.Is ou errors.As.
• Cada chamada que pode falhar tem seu próprio if err != nil, garantindo que o “bilhete de erro” seja lido antes que o próximo passo seja executado.

5. A filosofia da robustez

Depois de alguns ciclos de “saborear” o padrão if err != nil, ele deixa de ser um incômodo e passa a ser o termômetro que assegura que cada bebida (ou chamada de função) está na temperatura ideal antes de ser servida. O código ganha confiança porque sabemos exatamente onde cada falha foi tratada, como se cada copo fosse inspecionado antes de sair do balcão.

Além disso, ao tornar o erro um valor explícito, o compilador e as ferramentas de lint (por exemplo, staticcheck) nos lembram gentilmente de não deixar nenhum bilhete de erro sem leitura. Essa vigilância automática transforma a verbosidade do Go de “excesso de texto” em “documentação viva” que protege o sistema contra surpresas desagradáveis.

Resumo

• As exceções tradicionais escondem problemas como um barista que tenta consertar o café derramado sem avisar.
• Em Go, o erro é um valor retornado junto ao resultado, tão transparente quanto um bilhete ao lado do copo.
• O padrão if err != nil funciona como um cheque de qualidade antes de servir a bebida, prevenindo que o cliente receba um gole ruim.
• O exemplo atualizado usa os.ReadFile e fmt.Errorf("%w"), demonstrando boas práticas modernas.
• Ao adotar essa abordagem, ganhamos robustez, rastreabilidade e, sobretudo, a tranquilidade de saber que cada falha foi tratada antes de chegar ao usuário.