Tutorial Python Try-Except: Melhores práticas e exemplos reais

Quando o código Python encontra problemas durante a execução, geralmente gera uma exceção. Se não forem tratadas, as exceções vão travar o seu programa. Mas, com os blocos de e try-except, você pode pegá-los, se recuperar com facilidade e manter seu aplicativo funcionando.

Esse tutorial não é sobre o básico de exceções, já falamos sobre isso no nosso guia guia Tratamento de exceções e erros em Python. Em vez disso, vamos mergulhar fundo na prática do “ try-except ”: como estruturar seus blocos, evitar erros comuns e aplicar as melhores práticas que tornam seu código mais confiável em cenários reais.

No final, você vai entender não só como funciona o try-except, mas também como usá-lo à maneira Python: escrevendo código de tratamento de erros que seja claro, fácil de manter e pronto para produção.

Se você ainda tá aprendendo Python, recomendo dar uma olhada no programa de habilidades Fundamentos da Programação em Python, que vai te ajudar a desenvolver todas as habilidades essenciais.

Por que focar no try-except?

O tratamento de erros em Python é basicamente sobre criar programas que possam lidar com o inesperado. E, embora existam várias ferramentas para lidar com erros, o try-except é a espinha dorsal da abordagem do Python.

Por que isso é tão importante?

• Isso mostra a filosofia do Python. Em Python, o estilo comum éo EAFP( , ou seja, é mais fácil pedir perdão do que permissão) . Em vez de verificar tudo antes (esse arquivo existe? essa entrada é válida? o servidor está disponível?), você simplesmente tenta fazer a operação. Se não der certo, você pega a exceção e resolve. Isso deixa o código mais curto e mais limpo.
• Ele mantém o código funcionando em ambientes reais. As entradas do usuário vão ficar confusas, os arquivos vão sumir, as APIs vão falhar e as redes vão cair. Com o try-except, você pode escrever um código que não desmorona na primeira dificuldade, mas reage de forma inteligente.
• É flexível o suficiente para iniciantes e profissionais. Um iniciante pode usar try-except para capturar um ValueError ao converter uma entrada em um inteiro. Um sistema de produção pode usá-lo para registrar erros, tentar novamente operações com falha ou gerar exceções personalizadas que facilitam a depuração.

É por isso que este artigo foca em try-except. Dominar isso faz toda a diferença entre escrever scripts que só funcionam em condições perfeitas e criar softwares robustos, fáceis de manter e prontos para produção.

Anatomia de um bloco Try-Except

Na sua forma mais simples:

try:
    risky_thing()
except SomeError:
    handle_it()

Quando o Python encontra um erro dentro do bloco ` try `, ele pula para o bloco ` except ` correspondente, em vez de travar o programa.

Você também pode estender esse padrão com as cláusulas ` else ` e ` finally `:

try:
    do_something()
except ValueError:
    print("Bad value!")
else:
    print("All good.")
finally:
    clean_up()

Aqui está um exemplo básico que funciona:

try:
    x = int(input("Enter a number: "))
except ValueError:
    print("That wasn’t a number.")
else:
    print("You entered", x)
finally:
    print("Done.")

except trata o erro, else é executado apenas se tudo funcionar e, finalmente, é sempre executado, mesmo que você pressione Ctrl-C ou saia.

Você pode dominar os fundamentos do tratamento de entradas do usuário em Python, desde prompts básicos até técnicas avançadas de validação e tratamento de erros, usando nosso curso Python User Input:. Tutorial sobre manuseio, validação e melhores práticasdo .

Lidando com várias exceções

Às vezes, um except simplesmente não é suficiente. Diferentes caminhos de código podem falhar de maneiras diferentes, e tentar pegar tudo com um simples except: não é exatamente útil; pode esconder bugs e tornar a depuração uma dor de cabeça.

Digamos que você esteja tentando converter algo em um número inteiro e depois dividi-lo. Aqui está o que vocênão deve fazer em :

try:
    result = int(user_input) / 2
except:
    print("Something went wrong.")

Isso abrange tudo, incluindo coisas que você provavelmente não pretendia esconder, como erros de digitação em nomes de variáveis ou exceções inesperadas que apontam para problemas reais.

Em vez disso, seja específico:

try:
    result = int(user_input) / 2
except ValueError:
    print("That wasn't a number.")
except ZeroDivisionError:
    print("Division by zero?")

Se você tiver vários tipos de exceção que precisam ser tratados da mesma maneira, pode agrupá-los assim:

try:
    result = some_function()
except (TypeError, ValueError):
    print("Something was wrong with the data.")

Assim, você ainda fica ciente do que pode dar errado, sem precisar repetir o mesmo bloco várias vezes.

E tem também o except Exception, que é melhor do que o except, mas ainda é um pouco largo demais. É melhor você focar nos erros específicos que você espera encontrar.

Usando blocos else e finally

Quando o código dentro do bloco ` try ` é executado com sucesso e nenhuma exceção é levantada, o Python executa o bloco ` else `. 

try:
    user_id = get_user_id()
except LookupError:
    print("User not found.")
else:
    print("Welcome, user", user_id)

Isso ajuda a separar sua lógica de tratamento de exceções do caminho feliz, facilitando a leitura.

Depois, tem o site finally. Não importa o que aconteceu; ele funciona de qualquer maneira. Exceção? Ainda funciona. Sem exceção? Ainda funciona. O programa trava com Ctrl-C? Ainda funciona. Ótimo pra limpar as coisas:

try:
    f = open("data.txt")
    process(f)
except IOError:
    print("Couldn’t open file.")
finally:
    f.close()

Lembre-se: se o arquivo nunca foi aberto, talvez nem exista um f, então tome cuidado. Você pode usar o gerenciador de contexto do Python (with open(...) as f:) quando estiver trabalhando com arquivos. É mais seguro.

Se você quer aprender técnicas importantes, como tratamento de exceções e prevenção de erros, para lidar com a exceção KeyError no Python de forma eficaz, recomendo nosso tutorial Exceções KeyError do Python e como corrigi-las .

Melhores práticas e armadilhas comuns do try-except em Python

Vamos ser sinceros: escrever blocos de try‑except s é meio que uma arte. Quando bem feitos, eles evitam que seu programa trave. Se fizerem isso mal, eles vão esconder os bugs tão bem que você só vai perceber quando o aplicativo travar e os usuários começarem a reclamar.

Aqui estão alguns hábitos que vale a pena cultivar:

Mantenha os blocos de try bem apertados. Não coloque cem linhas de código dentro de um único try. Isso só torna mais difícil saber o que causou o problema. Em vez disso, envolva apenas o código que pode falhar:

# Good
try:
    value = int(data)
except ValueError:
    print("Couldn’t convert.")

# Bad
try:
    # Tons of unrelated logic
    value = int(data)
    do_more()
    something_else()
except ValueError:
    print("Huh?")

Evite verificar as condições antes de fazer a ação se for mais fácil só tentar e pegar o erro. Python tem um nome pra isso: EAFP, mais fácil pedir perdão do que permissão. Se você está verificando se um arquivo existe e, em seguida, abrindo-o, você está criando uma condição de corrida. Em vez disso:

try:
    with open("file.txt") as f:
        content = f.read()
except FileNotFoundError:
    print("No file.")

Esse padrão evita um problema comum em que o arquivo pode sumir entre a verificação e a chamada de abertura. Experimente essa coisa. Se não der certo, veja o que deu errado.

Além disso, evite ignorar erros capturando tudo e não fazendo nada. Não faça isso:

try:
    something()
except:
    pass

A menos que você realmente saiba o que está fazendo, é aqui que os insetos se escondem e se multiplicam. Se você precisar silenciar, seja específico:

try:
    something()
except TimeoutError:
    # okay to ignore in this case
    pass

E anote os erros em algum lugar. Engoli-los completamente significa que no futuro você não vai ter ideia do que deu errado.

Exceções integradas vs. personalizadas

O Python vem com várias exceções integradas, que cobrem um número surpreendente de casos. Você provavelmente já se deparou com alguns deles:

• ValueErrorQuando algo tem o tipo certo, mas um valor inválido, como int("hello").
• TypeErrorQuando você tenta usar uma operação no tipo errado, tipo somar uma string e um número.
• ZeroDivisionErrorVocê adivinhou, dividir por zero.
• FileNotFoundError: tentando abrir um arquivo que não existe.
• KeyErrorQuando uma chave está faltando em um dicionário.

Eles são bem úteis e, na maioria dos scripts ou aplicativos, são mais do que suficientes. Mas às vezes você vai querer levantar algo mais descritivo, algo que faça sentido no mundo do seu projeto, não só no Python.

Digamos que você esteja criando um aplicativo que processa pedidos online e queira mostrar um erro quando alguém tentar comprar algo que está fora de estoque. Você poderia usar apenas ValueError, mas isso é um pouco genérico. Isso não diz pra próxima pessoa que ler seu código o que aconteceu.

É aqui que as exceções personalizadas se destacam.

class OutOfStockError(Exception):
    pass

def check_inventory(product_id):
    if not in_stock(product_id):
        raise OutOfStockError(f"Product {product_id} is out of stock.")

Ao criar a exceção personalizada, você está adicionando uma camada de significado. Você também está se dando mais controle; você pode capturar apenas essa situação específica:

try:
    check_inventory("shirt-001")
except OutOfStockError:
    print("Sorry, that item is sold out.")

É uma coisinha, mas deixa seu código mais fácil de entender e manter, principalmente em projetos maiores. E funciona bem com registro e monitoramento, nomes de exceções personalizados são muito mais fáceis de pesquisar do que um vago “ ValueError ”.

Registro, reativação e encadeamento de exceções

Tem um momento que rola quando você tá depurando: você vê um traceback, fica olhando pra ele e percebe que não faz ideia do porquê de algo ter falhado. É aí que entra a exploração florestal. Não se trata só de registrar erros, mas de dar ao seu futuro eu (ou à sua equipe) as pistas necessárias para descobrir o que deu errado.

Digamos que você está capturando uma exceção e quer registrar isso antes de continuar:

import logging
logging.basicConfig(level=logging.ERROR)

try:
    do_something()
except ValueError as e:
    logging.error("Failed to do something: %s", e)
    raise

O comando “ raise ” no final é importante, pois ele relança a mesma exceção depois de registrá-la. Sem isso, você simplesmente engoliu o erro. Às vezes isso é bom, mas geralmente não é.

Depois, tem o truque do “ raise from ”. Isso é pra quando você tá lidando com um erro, mas precisa levantar outro, e não quer perder o original. Python permite encadeá-los:

try:
    connect_to_database()
except TimeoutError as e:
    raise ConnectionError("Database unavailable.") from e

Assim, o rastreamento conta toda a história. Você recebe a nova mensagem ConnectionError, mas também vê a mensagem TimeoutError que causou isso. 

Você também pode suprimir o erro original (o que normalmente não deve fazer) desta forma:

raise ConnectionError("Just this error, nothing else.") from None

Mas, a menos que você tenha um bom motivo, manter a cadeia completa ajuda todo mundo a entender o que deu errado e como isso se agravou.

Você pode aprender os fundamentos do registro em Python com nosso Tutorial de Logging em Python.

Exemplos reais e casos de uso

Uma coisa é falar sobre tratamento de exceções de forma abstrata, mas faz sentido quando você vê isso em código real.

Pega a entrada do usuário, por exemplo. Pergunte a qualquer pessoa que já tenha criado uma ferramenta de linha de comando ou um validador de formulários: os usuários digitam as coisas mais estranhas. Você quer um número? Alguém vai digitar “doze”. Ou colar um número de telefone. Ou é só apertar Enter. Acontece.

Em vez de escrever uma longa lista de verificações do tipo “e se”, você pode fazer o seguinte:

while True:
    user_input = input("Enter a number: ")
    try:
        number = int(user_input)
        break
    except ValueError:
        print("Try again with a whole number.")

Esse código não entra em pânico quando recebe uma entrada inválida. Ele diz pro usuário tentar de novo e fica repetindo até que tudo pareça estar certo. Muito mais simples do que empilhar instruções if para cada caso extremo.

Aqui vai outra: ler um arquivo que pode não existir.

try:
    with open("config.json") as f:
        settings = f.read()
except FileNotFoundError:
    print("Missing config file. Using defaults.")
    settings = "{}"

Não precisa verificar se o arquivo está lá. Tenta abrir e, se não der certo, segue em frente. Se você tivesse tentado verificar antes (os.path.exists()), alguém poderia ter apagado o arquivo entre a verificação e a abertura. Isso é uma condição de corrida, não algo que você queira depurar.

As solicitações de rede são outra mina de ouro para exceções. Você não pode sempre confiar que a internet vai funcionar direitinho. Os servidores ficam fora do ar. As conexões caem. O DNS não está funcionando. Então, se você estiver fazendo algo assim:

import requests

try:
    response = requests.get("https://example.com/data")
    response.raise_for_status()
except requests.exceptions.RequestException as e:
    print("Network problem:", e)

Essa classe base ` RequestException ` pega praticamente tudo que o ` requests ` pode gerar, desde tempos limite até respostas ruins. Você não precisa escrever dez blocos diferentes de except, a menos que queira lidar com eles de maneira diferente.

E se você estiver escrevendo scripts de automação ou serviços de back-end, colocar a lógica principal em blocos try-except pode fazer a diferença entre uma tarefa falhar e todo o sistema parar de funcionar. Você quer que os erros sejam registrados, as tarefas recuperáveis sejam repetidas e as irrecuperáveis sejam encerradas de forma limpa, sem traços de pilha enigmáticos rolando sem parar pelos seus registros.

Aprenda sobre automação em Python, incluindo conceitos básicos, bibliotecas importantes, como trabalhar com dados, usar melhorias de IA e as melhores práticas do nosso curso “ ” (Automação em Python: Fundamentos e Práticas). Um guia completo sobre o tutoria .

Try-except Python Usos avançados

A essa altura, você já deve ter percebido como o site try‑except pode ser flexível. Mas a flexibilidade tem dois lados. É fácil passar de prestativo a desleixado sem querer. Veja como manter tudo sob controle.

Capture exceções específicas. Se você sabe o que pode dar errado, diga:

try:
    result = int(data)
except ValueError:
    # Only catches invalid numbers, not everything else under the sun

Evite usar o except:. Não faça isso, a menos que esteja lidando com algo muito especial. Ele vai pegar coisas como KeyboardInterrupt, SystemExit e outras coisas que você provavelmente não quer silenciar.

Use else e finally quando eles deixarem o código mais claro. Não os force só porque eles existem. Se o caminho normal do seu código está ficando enterrado dentro de um ` try`, talvez seja melhor movê-lo para um ` else`.

Mantenha seus blocos de try pequenos. Quanto mais você inclui, mais difícil fica descobrir qual linha causou o erro. Envolva só a parte que pode dar problema. 

Registre os erros quando necessário, principalmente na produção. Mesmo que você não esteja enfrentando falhas, saber o que deu errado (e quando) facilita muito a depuração mais tarde.

As exceções personalizadas não são obrigatórias, mas ajudam. Se você tiver problemas específicos com o aplicativo, defina seus próprios erros. Eles podem tornar os registros mais legíveis e seu código mais autoexplicativo.

Só mais uma coisa: não use exceções para controlar o fluxo, a menos que não tenha outra opção melhor. É tentador escrever uma lógica do tipo “tente isso; se não der certo, faça aquilo”, mas se é algo que você espera que aconteça o tempo todo, provavelmente tem uma maneira mais simples.

Conclusão

Como expliquei ao longo deste artigo, o tratamento de exceções não se resume apenas a evitar falhas. Trata-se de escrever código que antecipe problemas, lide com eles sem drama e continue funcionando, ou seja encerrado de uma maneira que faça sentido. É a diferença entre um usuário receber uma mensagem útil e ser jogado de volta ao terminal com um rastreamento longo e ilegível.

Eu recomendo muito aprender mais sobre exceções, com alguns exercícios práticos, em nosso Capturando exceções em Python do nosso curso OOP em Python.