Tratamento de erros Python: tente/exceto/else/finalmente em 2026

O tratamento de erros separa o “código que funciona na sua máquina” do “código que sobrevive à produção”. O try / except do Python parece simples, mas a forma completa de quatro palavras-chave - try / except / else / finally - codifica uma quantidade surpreendente de estrutura que a maioria dos tutoriais ignora.

Este guia aborda: o que cada palavra-chave realmente significa, os seis padrões que você verá em cada base de código de back-end, quando definir suas próprias exceções e os três antipadrões que permitem que bugs escapem de seus testes.

As quatro palavras-chave, precisamente

A cláusula else é subutilizada. Diz "a próxima parte depende do sucesso da tentativa, mas não quero que ela seja protegida pela mesma exceção". É o lugar certo para a continuação do caminho feliz — colocá-lo dentro de try captura acidentalmente exceções não relacionadas de ship(result).

Os seis padrões

1. Tente novamente em caso de falha transitória

Regra: tente novamente SOMENTE em erros transitórios (rede, tempo limite, 429, 503). Nunca tente novamente em ValueError, KeyError, TypeError - esses são bugs de código, e tentar novamente apenas executa o bug três vezes.

2. Proteja com else

O else garante que file foi aberto com sucesso E delimita a limpeza com with. Aviso: process() pode gerar ValueError — que será propagado, NÃO será capturado por except FileNotFoundError.

3. Limpeza com finally (antes de with existir)

No código moderno, você usaria with db.connect() as conn: - with é o açúcar sobre try / finally para o caso de limpeza comum. Alcance o finally explícito somente quando o recurso não suportar o protocolo do gerenciador de contexto.

4. Aumente novamente com contexto adicional

raise NewException(...) from e encadeia a exceção original na nova para que o traceback mostre AMBOS. Nunca escreva raise NewException(str(e)) — isso descarta o traceback original.

5. Capture a exceção mais restrita possível

Regra: quanto mais restrito o exceto, melhor. Se você não sabe o que o process pode gerar, execute-o e descubra. except Exception: é um cheiro de código 90% das vezes.

6. raise dentro de except — re-raise limpo

Bare raise mantém o traceback original intacto. Nunca raise e (Python 3 é inteligente sobre isso, mas raise é a forma idiomática).

Exceções personalizadas — quando vale a pena

Defina sua própria classe de exceção quando:

1. Os chamadores precisam except MyError: especificamente (ou seja, você tem uma API que pode ser chamada e os usuários precisam ramificar de acordo com o tipo de falha).

2. Sua biblioteca/serviço gera vários erros relacionados que compartilham contexto.

Agora os chamadores podem capturar de forma ampla (except PaymentError) ou restrita (except CardDeclinedError). Atributos estruturados na exceção (e.card_last4) permitem que manipuladores de erros criem UX útil sem analisar mensagens de exceção.

Antipadrão: definir uma exceção personalizada que só existe para ser gerada uma vez e nunca capturada. Isso é apenas raise ValueError("..."). As exceções personalizadas ganham peso por serem capturadas.

Três antipadrões que escondem bugs

Antipadrão 1: Nu, exceto

Bare except captura sinais que devem sair do programa (Ctrl-C, sys.exit, MemoryError). Nunca escreva isso. Se você realmente deseja capturar todas as exceções não fatais, use except Exception: — que AINDA captura demais, mas pelo menos respeita Ctrl-C.

Antipadrão 2: Silenciar sem registrar

Cada exceção capturada deve ser tratada (com um fallback específico) ou registrada em log. pass em um exceto é um bug em câmera lenta - o código parece funcionar enquanto descarta dados silenciosamente.

Antipadrão 3: except Exception: em torno de tudo

Problema: se stripe.charge foi bem-sucedido, mas send_receipt falhou, o cliente foi cobrado E você engoliu o erro. O except cobre quatro modos de falha diferentes, e você não pode diferenciá-los.

Correção: estreitar o escopo try + ramificar o limite exceto pelo módulo.

Cada tentativa cobre UMA operação. Cada um, exceto sabe o que fazer com ESTA falha específica. Esse é o tratamento de erros de nível de produção.

Um bom tratamento de erros envolve mais design do que sintaxe. try / except / else / finally fornece as ferramentas; a disciplina é escolher o tipo de exceção correto, o escopo de tentativa mais restrito possível e nunca silenciar erros que você não entende.

Próxima etapa: o curso Foundations tem 10 lições sobre tratamento de exceções, exceções personalizadas e a instrução with — com Python real sendo executado em seu navegador.