raise from: encadear erros sem perder a causa

Traduzir erros de baixo nível

Uma prática comum e saudável é traduzir erros. Uma camada baixa do seu código pode falhar com um erro técnico, como um KeyError ao ler um dicionário ou um ValueError ao converter um texto. Repassar esse erro cru para quem chamou a sua função vaza detalhes de implementação e confunde. O melhor é capturar o erro técnico e levantar uma exceção do seu domínio, com uma mensagem clara. O cuidado é não jogar fora a causa original, que é ouro na hora de depurar.

class ConfigInvalida(Exception):
    pass

def ler_porta(config):
    try:
        return int(config["porta"])
    except KeyError as e:
        raise ConfigInvalida("faltou a chave porta") from e
    except ValueError as e:
        raise ConfigInvalida("porta precisa ser um numero") from e

try:
    ler_porta({"host": "localhost"})
except ConfigInvalida as erro:
    print(erro)              # faltou a chave porta
    print(repr(erro.__cause__))  # KeyError('porta')

raise ConfigInvalida(...) from e preserva o KeyError original em __cause__.

O from e é o que faz a mágica. A função devolve um erro limpo do domínio, ConfigInvalida, mas guarda o KeyError original em __cause__. No rastreamento completo, o Python imprime as duas exceções, com a frase A causa direta da exceção acima foi entre elas. Quem lê o log entende tanto o que deu errado do ponto de vista do domínio quanto a causa técnica exata, sem precisar adivinhar. É a diferença entre um log que ajuda e um que esconde.

__cause__ e __context__

O Python encadeia exceções de duas formas. Quando você usa raise ... from ..., ele preenche __cause__: uma ligação explícita, feita por você, dizendo que um erro foi a causa direta do outro. Mas há também o encadeamento implícito. Se uma exceção acontece dentro de um bloco except, enquanto você já tratava outra, o Python preenche __context__ automaticamente, mesmo sem from. No rastreamento, isso aparece como Durante o tratamento da exceção acima, ocorreu outra exceção.

A distinção importa na prática. O __context__ implícito é útil, mas às vezes polui o rastreamento com um erro intermediário que não interessa a quem lê. Quando você usa from explicitamente, deixa claro qual é a causa que importa. E, quando quer suprimir a cadeia de propósito, existe o from None, que oculta a causa. Um caso típico é uma função pública que não quer expor detalhes internos: ela traduz o erro e usa from None para mostrar só a mensagem limpa, sem o rastro técnico.

Quando ocultar a causa

class UsuarioNaoEncontrado(Exception):
    pass

_banco = {"ana": 1, "bruno": 2}

def id_do_usuario(nome):
    try:
        return _banco[nome]
    except KeyError:
        # Aqui a causa tecnica (KeyError) nao agrega nada a quem chama.
        raise UsuarioNaoEncontrado(f"usuario {nome!r} nao existe") from None

try:
    id_do_usuario("carla")
except UsuarioNaoEncontrado as e:
    print(e)              # usuario 'carla' nao existe
    print(e.__cause__)    # None: a causa foi ocultada de proposito

from None oculta o KeyError interno, expondo só a mensagem clara do domínio.

O bom senso aqui é claro: preservar a causa deve ser o padrão, e ocultá-la, a exceção. Um KeyError que revela a estrutura interna de um dicionário privado talvez não interesse a quem consome uma API pública, e nesse caso from None limpa o rastreamento sem perda real. Mas nunca use from None para esconder um erro que você não entendeu, porque é exatamente a causa que você precisa ver depois. Encadear bem é um dos hábitos que mais economizam tempo de depuração num sistema em produção.