Python trabalhando com dados externos: quando o erro também é um dado

Quando desenvolvemos uma rotina em Python para trabalhar com dados externos, existe uma diferença importante entre fazer o código funcionar e fazer o processamento ser confiável.

Um arquivo pode estar ausente.

Uma API pode não responder.

Um CSV pode chegar com outro delimitador.

Uma coluna pode desaparecer.

Um valor que deveria ser numérico pode chegar como texto.

Uma codificação diferente pode alterar a interpretação dos dados.

E existe um problema ainda mais interessante:

o programa pode executar sem gerar nenhuma exceção e, mesmo assim, produzir um resultado incorreto.

É nesse ponto que tratamento de exceções e depuração deixam de ser apenas recursos da linguagem e passam a fazer parte da qualidade do processo.

1. Dados externos não são uma extensão do nosso código

Quando uma aplicação recebe dados de outra fonte, existe uma fronteira entre o que controlamos e o que não controlamos.

O Python possui recursos para trabalhar com arquivos, CSVs e recursos externos. O módulo csv, por exemplo, permite trabalhar com diferentes formatos de dados tabulares, mas a própria documentação alerta que existem diferenças entre arquivos CSV produzidos por diferentes aplicações.

Isso significa que não deveríamos começar a implementação pensando apenas:

"Como faço para ler esse arquivo?"

Uma pergunta mais importante seria:

"Quais condições preciso validar para considerar esse arquivo confiável para processamento?"

Essa mudança de perspectiva é pequena, mas muda completamente a qualidade da solução.

Podemos precisar verificar:

• existência do arquivo;
• formato esperado;
• codificação;
• delimitador;
• estrutura das colunas;
• tipos dos dados;
• campos obrigatórios;
• valores nulos ou inválidos;
• duplicidades;
• quantidade de registros;
• consistência com regras conhecidas.

O objetivo não é impedir que dados externos tenham problemas.

É fazer com que o sistema saiba identificar quando eles não estão dentro das condições esperadas.

2. Exceção não é sinônimo de problema resolvido

Python possui um mecanismo estruturado para tratamento de exceções com try e except. A documentação recomenda tratar especificamente as exceções que realmente sabemos como tratar e permitir que situações inesperadas continuem sendo propagadas quando necessário.

Isso traz uma reflexão importante.

Existe uma diferença entre:

erro ocorreu

e:

erro ocorreu
→ foi identificado
→ foi registrado
→ foi classificado
→ houve uma decisão sobre o que fazer

Capturar qualquer exceção indiscriminadamente pode esconder justamente o problema que deveria chamar nossa atenção.

Em uma rotina de processamento, por exemplo, transformar qualquer falha em:

"Erro ignorado. Continuando..."

pode fazer o programa terminar aparentemente com sucesso enquanto parte dos dados deixou de ser processada.

Em determinados cenários, falhar explicitamente pode ser mais seguro do que continuar silenciosamente.

A própria documentação do Python apresenta como boa prática utilizar handlers específicos e permitir que exceções inesperadas sejam propagadas. Também mostra o uso de raise e o encadeamento de exceções para preservar o contexto da causa original.

3. O log não deve apenas dizer que falhou

Outro ponto importante é a observabilidade.

O módulo logging do Python fornece diferentes níveis de severidade, como DEBUG, INFO, WARNING, ERROR e CRITICAL, permitindo registrar eventos relevantes durante a execução.

Mas existe uma diferença entre ter logs e ter logs úteis.

Imagine encontrar:

ERROR: processamento falhou

Isso informa que algo aconteceu.

Agora imagine conseguir identificar:

arquivo recebido
→ etapa de validação
→ registro processado
→ regra rejeitada
→ exceção
→ etapa em que ocorreu

A segunda situação fornece muito mais capacidade de investigação.

Em sistemas corporativos, rastreabilidade pode ser tão importante quanto o próprio tratamento do erro.

O objetivo não é registrar tudo indiscriminadamente, mas produzir informações suficientes para responder:

O que aconteceu?

Onde aconteceu?

Quando aconteceu?

Qual etapa foi afetada?

O processamento continuou ou foi interrompido?

E, principalmente:

O resultado produzido ainda pode ser considerado confiável?

4. Depuração não é apenas procurar a linha vermelha

Quando uma exceção ocorre, o traceback fornece informações sobre o caminho percorrido pelo programa até o erro.

Mas nem todo problema é uma exceção.

Às vezes o programa executa normalmente:

entrada → processamento → saída

e o resultado está errado.

Nesse caso, precisamos investigar o estado da aplicação durante a execução.

É aí que ferramentas de depuração podem ajudar. O pdb, debugger padrão do Python, permite utilizar breakpoints, executar o código passo a passo, inspecionar frames e avaliar expressões durante a execução. Ele também suporta depuração post-mortem.

Isso permite mudar a pergunta de:

"Qual linha quebrou?"

para:

"Em que momento o comportamento deixou de ser o esperado?"

Essa diferença é fundamental.

5. O problema mais perigoso pode não gerar exceção

Considere uma rotina que recebe registros externos.

O arquivo chega.

O Python consegue abrir.

O parser consegue interpretar.

As funções executam.

Nenhuma exceção acontece.

Porém, uma coluna mudou de significado.

O programa continua funcionando.

O resultado também é gerado.

Tecnicamente, a execução foi bem-sucedida.

Funcionalmente, pode estar errada.

Esse é um dos motivos pelos quais tratamento de exceções não substitui validação de dados.

Exceções ajudam a lidar com situações anormais durante a execução.

Validações ajudam a determinar se aquilo que estamos processando atende às condições esperadas.

São problemas diferentes.

6. Uma rotina confiável precisa saber quando não deve continuar

Uma arquitetura de processamento mais madura poderia seguir uma lógica conceitual como:

Entrada externa
    ↓
Validação estrutural
    ↓
Validação dos dados
    ↓
Processamento
    ↓
Validação do resultado
    ↓
Registro da execução
    ↓
Saída

E, caso alguma condição crítica seja violada:

Entrada
 ↓
Validação
 ↓
Falha
 ↓
Registro
 ↓
Interrupção ou tratamento controlado
 ↓
Intervenção

A decisão entre continuar, rejeitar apenas um registro, interromper o lote ou solicitar intervenção humana depende do contexto e das regras do processo.

Não existe um except universalmente correto.

7. A pergunta que realmente importa

Quando trabalhamos com dados externos, talvez a pergunta mais importante não seja:

"Como evitar que o programa dê erro?"

Mas:

"Como garantir que o programa não produza um resultado aparentemente válido quando as condições de entrada ou processamento não são confiáveis?"

Essa mudança de perspectiva aproxima desenvolvimento, qualidade, operação e segurança.

Porque um sistema confiável não é aquele que nunca falha.

É aquele que consegue detectar, registrar, explicar e tratar suas falhas de maneira previsível, sem transformar uma situação desconhecida em um resultado aparentemente normal.

E talvez exista uma regra simples por trás disso:

Um processamento silenciosamente errado pode ser mais difícil de detectar do que um processamento que falha explicitamente.

Por isso, trabalhar com dados externos em Python não é apenas uma questão de sintaxe, bibliotecas ou try/except.

É uma questão de confiabilidade do resultado.

Referências

As referências principais são a documentação oficial do Python, especialmente:

• Tratamento de erros e exceções — try, except, raise, finally e encadeamento de exceções.
• Módulo csv — leitura/escrita e particularidades de arquivos CSV provenientes de diferentes fontes.
• logging — níveis de severidade, rastreamento de eventos e registro de exceções.
• pdb — debugging interativo, breakpoints, inspeção de frames e depuração post-mortem.
• urllib — recursos da biblioteca padrão para trabalhar com URLs e recursos externos.

Documentação oficial do Python — Conteúdo

Python — Erros e exceções

Python — Logging HOWTO

Python — pdb Debugger

Python — módulo csv