Tratar exceções com try, except, else e finally

O script chama executar, que chama calcular_metade, que chama converter. O erro surge na função mais interna, mas o traceback também registra as chamadas que levaram até ela. Considere as linhas em branco ao acompanhar a numeração.

O caminho exibido para o arquivo pode variar no seu computador.

Comece pela última linha: ValueError é o tipo da exceção, e o texto após os dois-pontos é sua mensagem. Depois, examine os quadros acima. Cada quadro informa o arquivo, o número da linha e o local de execução — uma função ou <module>, quando a linha está no nível principal do script.

Os quadros aparecem da chamada mais externa para o ponto mais interno apresentado: linha 14 → linha 11 → linha 6 → linha 2.

Coloque no try a operação que pode produzir a falha esperada. Se int() não conseguir converter o texto, ele produz um ValueError: a execução abandona imediatamente o restante do try e procura um except compatível.

Execute mentalmente o código e observe que as mensagens 3 e 4 não são exibidas.

A conversão ocorre em converter, mas o tratamento está em mostrar_quantidade, que chamou essa função.

O ValueError sai de converter e se propaga até o except ValueError no chamador. O tratamento não retoma a função no ponto interrompido: conversão terminada não é exibida, nem um valor é retornado por aquela chamada.

Em except ValueError as erro, a escolha do tratamento depende do tipo ValueError. O nome erro dá acesso ao objeto da exceção e à sua mensagem, que pode ser exibida em uma f-string. Se a exceção não for compatível com ValueError, ela continuará se propagando; nesse caso, o código após a estrutura não será alcançado por esse fluxo.

Quando cada tipo de falha exige uma resposta diferente, use cláusulas except separadas. Neste exemplo, uma conversão inválida produz ValueError, enquanto a divisão por zero produz ZeroDivisionError.

Observe que cada cláusula produz uma mensagem adequada ao tipo de falha.

Quando uma exceção sai do try, o Python examina as cláusulas except de cima para baixo. Ele executa somente a primeira compatível e não continua procurando outros tratamentos. Se nenhuma for compatível, a exceção continua se propagando.

O fluxo pode chegar ao tratamento de conversão, ao tratamento de divisão por zero ou sair da estrutura sem tratamento.

Se as falhas devem receber exatamente o mesmo tratamento, coloque os tipos em uma tupla. O agrupamento deve representar uma decisão do programa, não apenas uma tentativa de reduzir linhas.

Agora as duas falhas previstas recebem a mesma resposta.

O bloco else associado a try é executado somente quando o try chega ao fim sem produzir uma exceção. Se uma exceção surgir no try, o fluxo procura um except compatível e não passa pelo else — mesmo quando a exceção é tratada.

Isso permite deixar no try apenas a operação sujeita à falha esperada e mover para o else as ações que dependem do resultado bem-sucedido.

Execute o código e compare as duas chamadas.

Há três caminhos importantes:

• Se o try terminar sem exceção, o fluxo segue para o else.
• Se o try produzir uma exceção compatível, o fluxo segue para o except e ignora o else.
• Se o try terminar com sucesso, mas uma operação no else falhar, essa nova exceção sai da estrutura e continua se propagando.

No código abaixo, int("0") termina normalmente, então o else é iniciado. A divisão por zero acontece dentro dele. Como os except desta estrutura tratam exceções produzidas no try, o ZeroDivisionError não é capturado pelo except ValueError e continua se propagando.

Ao executar, a primeira mensagem aparece antes do traceback.

O bloco finally é executado quando o fluxo sai da estrutura try, seja após o sucesso, após um except ou enquanto uma exceção não tratada está se propagando.

Nos caminhos mais comuns:

• sucesso: try → else → finally → depois da estrutura;
• exceção tratada: try → except → finally → depois da estrutura;
• exceção não tratada: try → finally → propagação.

Executar finally não significa que o erro foi tratado. Se ainda houver uma exceção pendente e o finally terminar normalmente, ela continuará se propagando.

Observe que todos os caminhos chegam ao bloco dourado. Somente os caminhos sem uma exceção pendente seguem para a continuação normal.

A função abaixo registra a passagem pelos blocos em uma lista. Execute cada chamada separadamente, pois o terceiro cenário termina com uma exceção não tratada.

Uma nova exceção pode surgir durante um except, assim como pode surgir no else. Nesses casos, finally ainda é executado antes da propagação. Ele realiza sua ação de encerramento, mas não recupera o programa automaticamente.

Quando o Python encontra return dentro de try, ele prepara o valor de retorno, mas executa finally antes de sair da função. Como o try não chegou normalmente ao fim, o bloco else não é executado.

Se o próprio finally executar outro return, esse novo retorno substituirá o anterior.

Execute o código e observe que a mensagem do else não aparece.

Se houver uma exceção pendente, o finally ainda será executado. Porém, um return dentro dele encerra a função com um valor e suprime a exceção. A ação de encerramento aconteceu, mas a falha inesperadamente deixou de se propagar.

Compare os caminhos: um encerramento normal permite que o retorno ou a exceção pendente continue; um novo retorno criado no finally ocupa a saída e descarta o que estava pendente.

int("abc") produz ValueError, mas o return de finally oculta essa falha.

Mantenha no finally somente as ações que devem ocorrer em qualquer caminho. O tratamento específico, o processamento de sucesso e a decisão de retorno ficam fora dele.

Agora o encerramento sempre ocorre, mas não altera a decisão tomada pelos outros blocos.

Analise as duas funções antes de responder.

Uma exceção é esperada quando faz parte das falhas previstas para uma operação específica. Por exemplo, ao converter um texto fornecido pelo usuário com int, um ValueError pode ser uma entrada que o programa sabe tratar. Mas um ValueError em outra operação pode indicar um defeito.

Por isso, não basta perguntar “qual é o tipo da exceção?”. Também é necessário perguntar “qual operação poderia produzir esse erro e por que ele é esperado aqui?”.

O try deve envolver somente a operação cuja falha foi prevista. Operações posteriores ficam fora dessa fronteira para que seus erros não sejam confundidos com a falha esperada.

A conversão pode falhar com ValueError, mas list.index também produz esse tipo quando não encontra o item. O código abaixo transforma até o erro de digitação interno em uma mensagem sobre a entrada.

Agora, somente a conversão está no try. Uma entrada como "doze" recebe o tratamento planejado. Com "12", o erro de digitação em index permanece visível porque exceções produzidas no else não são capturadas pelo except associado.

except Exception captura muitos erros que podem não fazer parte da recuperação planejada, como falhas de índice, operações com tipos incompatíveis ou divisões por zero. Se todos virarem None, 0 ou uma mensagem genérica, defeitos podem passar despercebidos.

Um except sem tipo tem alcance ainda maior e pode interceptar inclusive uma interrupção feita pelo usuário pelo teclado. Para uma falha conhecida, prefira o tipo específico e um try restrito à operação correspondente.

A conversão de texto_indice é a única falha esperada neste cenário. As operações com a lista devem manter visíveis falhas não previstas.

Copie o script abaixo para um arquivo .py no seu computador. Ele calcula uma razão usando apenas dados em memória, mas apresenta três problemas: o try inclui processamento posterior, except Exception captura também a falha inesperada e há um return dentro de finally.

Refatore a função para:

1. manter no try somente as conversões e a divisão;
2. tratar ValueError e ZeroDivisionError separadamente;
3. acessar cada mensagem com as erro;
4. colocar o cálculo com fator e a mensagem de sucesso no else;
5. registrar o encerramento no finally, sem executar return nele.

Altere somente a função calcular_razao. Para cada execução, escolha um dos quatro nomes em CENARIO.

Nesta versão, somente as falhas esperadas das conversões e da divisão são capturadas. O processamento que depende do resultado fica no else. Se esse processamento falhar, os except associados ao mesmo try não interceptam a nova exceção.

Substitua a função inicial por esta versão e mantenha o restante do script.

Observe que todos os caminhos passam pelo encerramento, mas somente três terminam normalmente.

Execute separadamente sucesso, conversao, divisao_zero e inesperada.

No sucesso, procure resultado: 8.00 | encerramento. Nos dois erros esperados, confirme a mensagem específica seguida de encerramento. No cenário inesperado, o finally imprime encerramento, mas depois aparece um traceback de TypeError.

Leia esse traceback de fora para dentro: localize primeiro a chamada de calcular_razao no código de nível superior e depois a multiplicação resultado * fator dentro da função. A última linha informa o tipo e a mensagem da falha.