Quando a adição quebra
A operação mais básica da aritmética pode falhar de formas inesperadas quando sai do papel. Já vi sistema de pagamento estourar porque um contador de centavos chegou no limite do inteiro de 32 bits e virou negativo. Não é teoria. É o que acontece quando ninguém pensa no overflow antes de colocar em produção.
problema de adicao em sistemas reais
O problema de adicao que mais causa dor de cabeça em produção é o integer overflow. Em linguagens como C e C++, somar dois inteiros grandes pode fazer o valor "dar a volta". Quando você tem 2147483647 + 1, o resultado vira -2147483648. Se esse valor for usado para calcular preço, quantidade em estoque ou timestamp, o estrago já está feito. No meu caso, tive um serviço de logística que começou a mostrar fretes negativos porque a soma de peso bruto mais tarja ultrapassava o limite do int. O código parecia certo. A lógica estava boa. Só faltava verificar se a soma caberia no tipo antes de executar.
Existem formas de evitar. Em C++11 e versões mais recentes, você pode usar funções da biblioteca padrão como std::add_overflow. Elas retornam true quando acontece o estouro, em vez de deixar o programa continuar com um valor errado. Funciona assim: int a = 2147483647, b = 1, resultado;
if (std::add_overflow(a, b, &resultado)) { /* tratar erro */ } Isso corta o tempo de debugging de horas para minutos. Você parametricamente já sabe onde a falha ocorre.
precisão de ponto flutuante
Outro cenário onde adição falha é com floats. O famoso 0.1 + 0.2 não é exatamente 0.3 na maioria das linguagens. Isso acontece porque números decimais não têm representação exata em binário. O resultado fica algo como 0.30000000000000004. Em sistemas financeiros isso é inaceitável. Já entrei em empresa onde precisaram refazer todo o módulo de cobranças porque as somas de parcelas apresentavam diferenças de centavos acumulas ao longo de meses. A solução foi abandonar float e usar tipos decimais ou trabalhar sempre com inteiros representando centavos.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Em Python, o módulo decimal resolve boa parte disso. Em JavaScript, existe a biblioteca decimal.js ou você pode fazer tudo em inteiros e dividir só na exibição. A escolha errada de tipo custa caro depois.
vieses comuns
Começantes costumam achar que validar entrada é suficiente. Não é. Você precisa validar o resultado também. Outro erro clássico é confiar em bibliotecas externas que prometem resolver tudo sem ler a documentação. Muitas tratam overflow de forma silenciosa, o que é pior que explodir com erro claro. Funções matemáticas também podem ter problemas. Somar valores muito diferentes em magnitude pode causar perda de precisão. Exemplo: somar 1e20 com 1. Em float de precisão simples, o resultado é apenas 1e20. O 1 some porque não cabe na precisão disponível.
Para contornar, organize a ordem das somas. Some os valores menores primeiro. Isso preserva mais precisão. Em cálculos científicos faz diferença. Em controle de estoque também.
testes práticos
Colocar testes de borde no CI ajuda. Teste com MAX_VALUE, MAX_VALUE + 1, valores negativos, floats edge cases. Um único teste de overflow já pega muitos bugs antes de chegar em produção. Se precisar de uma referência rápida sobre como implementar verificação de overflow em diferentes linguagens, dá uma pesquisada nas documentações oficiais. Cada uma tem sua forma. Nem sempre é intuitiva no começo, mas compensa quando a coisa estoura mesmo.
O que funciona hoje pode falhar amanhã se os dados crescero. Manter a sanidade nos limites dos tipos é trabalho chato, mas evita dor muito maior depois.
