Encadeamento e boas práticas

O que não fazer com exceções

O pior hábito com exceções é o except vazio que não faz nada, às vezes com um pass dentro. O programa realmente para de quebrar, mas por um motivo terrível: ele passou a ignorar todos os erros, inclusive os que apontam bugs de verdade. Um dia o cálculo dá resultado errado, ninguém entende por quê, e a resposta é que um except mudo estava engolindo a exceção que explicava tudo. Errar em silêncio é pior que quebrar, porque a quebra ao menos avisa. Se você não sabe tratar um erro, é melhor deixá-lo aparecer.

# ANTIPADRÃO: engole tudo em silêncio
try:
    total = calcular(pedido)
except:
    pass  # e agora ninguém sabe que algo falhou

# MELHOR: trate o que você espera, deixe o resto subir
try:
    total = calcular(pedido)
except ValueError as erro:
    print("Pedido inválido:", erro)

O except vazio com pass esconde qualquer falha; o específico trata só o previsto.

A regra de ouro é capturar o mais específico que você sabe tratar. Se a função pode falhar por ValueError, escreva except ValueError. Se pode falhar de duas formas, escreva os dois except. Não estenda a captura para tipos que você não entende só por precaução, porque isso volta a esconder o inesperado. Pense assim: cada except é uma promessa de que você sabe o que fazer com aquele erro. Não faça promessas que não pode cumprir.

Mensagens úteis e o raise from

Uma boa mensagem de erro economiza minutos ou horas de investigação. Compare "erro ao processar" com "data de nascimento inválida: 32/13/2020". A segunda diz o que falhou e mostra o dado problemático. Sempre que levantar uma exceção, inclua contexto: qual regra foi violada, qual valor chegou, o que era esperado. Essa mensagem viaja com a exceção e aparece no traceback ou na variável capturada com as, então o esforço de escrevê-la bem se paga toda vez que o erro acontece.

Às vezes você captura um erro de baixo nível e quer levantar outro, mais adequado ao seu programa. Ao fazer isso, é fácil perder a pista da causa original. O raise from resolve: ele levanta a nova exceção mantendo o vínculo com a que a provocou. No traceback, o Python mostra as duas e explica que uma foi a causa direta da outra. Assim, quem depura vê tanto o erro que você escolheu expor quanto a falha técnica que o gerou, sem ter que adivinhar.

class ConfiguracaoInvalidaError(Exception):
    pass


def ler_porta(texto):
    try:
        return int(texto)
    except ValueError as erro:
        raise ConfiguracaoInvalidaError(f"Porta inválida: {texto!r}") from erro

ler_porta("abc")

# Traceback (most recent call last):
#   ... ValueError: invalid literal for int() with base 10: 'abc'
#
# The above exception was the direct cause of the following exception:
#   ... ConfiguracaoInvalidaError: Porta inválida: 'abc'

O raise from liga a exceção nova à original; o traceback mostra as duas encadeadas.

Fixando as boas práticas

Boas práticas de exceção têm um fio comum: não esconder a verdade. O except vazio esconde; o tipo específico revela. A mensagem pobre esconde; a mensagem com contexto revela. Trocar uma exceção por outra sem raise from esconde a causa; com raise from, a causa fica registrada. Programar defensivamente não é abafar erros, é lidar com eles de forma que o problema, quando aparecer, seja fácil de entender e corrigir. Com esses hábitos firmes, você está pronto para a prática do módulo: uma função de saque robusta, do jeito certo.