Construindo uma Pipeline de Dados Resiliente: Validação e Tratamento de Erros na Prática

Nos artigos anteriores, celebramos os ganhos de flexibilidade e a performance estonteante da nossa nova aplicação. Mas existe um terceiro pilar, muitas vezes subestimado, que sustenta o sucesso de qualquer sistema de dados: a confiança. De que adianta um processo rápido e flexível se ele permite a entrada de dados incorretos, gerando inconsistências silenciosas que só serão descobertas tarde demais?
Neste artigo, vamos explorar como construímos uma pipeline de dados resiliente, focada em garantir a qualidade da informação através de uma filosofia de validação proativa e um tratamento de erros inteligente.

A Filosofia de Design: "Reporte o Erro, Mas Não Pare o Mundo"

A primeira grande decisão arquitetural foi sobre como lidar com falhas. Em um processo que manipula 600.000 registros, a chance de encontrar um dado mal formatado é de praticamente 100%. A abordagem tradicional de "parar no primeiro erro" é terrivelmente ineficiente. Manter 599.999 registros válidos reféns de um único dado inválido era inaceitável.
Eu adotei a filosofia de "reportar e continuar". O trabalho da aplicação é processar tudo que for válido e, ao final, apresentar um relatório claro e acionável de tudo que falhou. Dentro dos laços de processamento em automato.cpp, cada registro passa por uma série de validações. Se um registro falha em qualquer uma delas, ele é simplesmente descartado do lote de processamento, uma entrada é adicionada ao log, e o laço continua para o próximo registro com um continue;. Isso garante máxima produtividade e coloca o poder da correção nas mãos do usuário.

A Linha de Defesa: Validações Pró-ativas

Para garantir a qualidade, implementamos múltiplas camadas de validação que atuam como uma linha de defesa contra dados ruins.

1. Validação de Documentos (CPF/CNPJ): O Básico Essencial

A validação mais crítica é a de documentos. Para isso, eu implementei rotinas específicas, como validacpf() e validacnpj(), que implementam os algoritmos de verificação de dígitos para garantir que os números fornecidos são matematicamente válidos. Eu criei a função principal para orquestrar essa validação, tratando diferentes formatos de entrada (com ou sem máscara, com 11 ou 14 dígitos) e projetei para que retornasse códigos de erro específicos que nos permitem gerar mensagens claras para o usuário.

2. Validação de Formato: O Perigo da Notação Científica

Um dos problemas mais traiçoeiros ao lidar com planilhas é a formatação automática do Excel. Um número de CPF ou CNPJ muito longo, se não formatado como texto, pode ser convertido para notação científica (ex: 1.23456E+10), corrompendo o dado original. Para nos proteger disso, criamos uma função que verifica se é ou não notação científica.

Snippet de Código 1:

// Função de checagem em automato.cpp
bool ehnotacao(AnsiString dado)
{
    // A lógica é simples e eficaz: se a string contém "E+",
    // ela foi convertida e é inválida para um documento.
    if(!dado.IsEmpty()) {
        if(dado.Pos("E+") > 0)
            return true;
    }
    return false;
}

Essa verificação simples, feita logo no início da leitura dos dados, nos permite identificar e descartar proativamente linhas com esse tipo de corrupção, prevenindo erros complexos em etapas futuras.

3. Validação de Dados Obrigatórios

Antes mesmo de iniciar o processamento das 600.000 linhas, a aplicação realiza uma verificação crucial no cabeçalho da planilha. Após a fase de mapeamento (descrita no Artigo 2), temos uma função que checa se todas as "variáveis de negócio" marcadas como obrigatórias foram devidamente associadas a uma coluna (leia também o artigo "Construindo um Motor de ETL Flexível: Mapeamento Dinâmico de Planilhas com C++"). Se, por exemplo, o sistema não encontrou uma coluna correspondente para [MOTIVO] em um script X, por exemplo, o processo é interrompido com uma mensagem clara, evitando que o processamento em massa comece com uma configuração inválida.

A Arquitetura de um Log Útil: Do Erro à Ação

Um log de erros só tem valor se ele ajuda o usuário a resolver o problema. Uma mensagem como "Erro na linha 5000" é inútil. Por isso, a arquitetura de log da nossa aplicação foi projetada para ser acionável.

Cada mensagem de erro gerada e adicionada ao log segue uma estrutura padronizada, como neste exemplo:

Snippet de Código 2:

Vamos analisar o que torna essa mensagem eficaz:

• Código do Erro (Erro 103): Permite categorizar a falha e facilita a busca por soluções.
• Contexto Preciso (Número da Linha): O IntToStr(linha) é a informação mais vital. Ele diz ao usuário exatamente em qual linha da planilha original o problema se encontra.
• Identificador do Dado (CPF/CNPJ: " + variavel): Mostra o dado problemático, facilitando sua identificação visual no arquivo.
• Descrição Clara: Uma explicação em linguagem humana sobre o que está errado ("tem menos de 11 digitos").

Essa estrutura transforma o log de um simples registro de falhas em um guia prático para a correção dos dados.

Conclusão: Construindo Confiança Através do Código

Velocidade e flexibilidade foram os resultados mais visíveis da nossa modernização. No entanto, foi a obsessão pela qualidade e resiliência dos dados que construiu a confiança dos usuários na nova ferramenta.
Ao adotar uma filosofia de "reportar e continuar", implementar múltiplas camadas de validação proativa e projetar um sistema de log que capacita o usuário a corrigir seus próprios dados, a aplicação deixou de ser apenas uma ferramenta de processamento para se tornar uma parceira na garantia da qualidade da informação. No final, a confiança nos dados é o ativo mais valioso que um sistema de software pode entregar.