O que é um caso de borda?

É uma entrada dos extremos do que o programa aceita: a lista vazia, o único item, o zero, o valor máximo, o negativo, o texto em branco. Bugs se escondem aí porque o programador costuma testar só o caso comum. Testar os extremos de propósito revela problemas que o caminho feliz esconde.

Por que os bugs se escondem nos extremos?

Porque o caso comum é o que todo mundo testa e ajusta até funcionar. Os extremos são fáceis de esquecer: quem lembra de testar a lista vazia ou o valor máximo? E são justamente eles que quebram laços, causam divisões por zero e revelam suposições erradas. Por isso a revisão precisa caçar os extremos.

O que é programação defensiva?

É escrever o código antecipando o que pode dar errado e protegendo-o contra isso: casos de borda, entradas ruins, o inesperado. Em vez de supor que tudo virá perfeito, você assume que listas chegam vazias e usuários digitam bobagens, e decide de antemão como reagir. Reúne guardas, validação e tratamento de exceções.

Programar defensivamente não deixa o código enorme?

Um pouco maior, sim, mas não por medo excessivo, e o ganho compensa de sobra. As checagens defensivas costumam ser poucas linhas no começo das funções (guardas), e evitam quebras e bugs difíceis lá na frente. Um código sem nenhuma defesa é menor, mas frágil: quebra ao primeiro imprevisto do mundo real.

O que significa falhar com clareza?

É, diante de uma situação que realmente não deveria acontecer, parar e avisar exatamente o que deu errado e onde, com uma mensagem clara, em vez de continuar produzindo resultados sem sentido em silêncio. Uma boa mensagem de erro vale ouro para quem conserta e é muito melhor que um resultado absurdo saindo calado.

Falhar com clareza não é o oposto de robustez?

Parece, mas não é. Robustez é tratar o esperado com elegância e denunciar o impossível com honestidade. Mascarar um estado impossível, seguindo em frente calado, é o que gera os piores bugs de lógica. Um programa robusto sabe a hora de tratar e a hora de falhar alto, para o problema ser corrigido em vez de escondido.

Módulo 13 - Quando dá errado: erros e robustez

Casos de borda e programação defensiva

8 min de leitura · por Cesar Gargiulo, revisado pela equipe ValorFinal e GuardiaSec · Atualizado em 08/07/2026

O que você vai aprender

Reconhecer os casos de borda que mais escondem bugs.
Adotar a programação defensiva: antecipar o inesperado.
Falhar com clareza quando algo realmente foge do previsto.
Testar os extremos de propósito antes de considerar o código pronto.

Os extremos onde os bugs moram

Ao longo do curso, você viu essa ideia aparecer várias vezes, e agora ela ganha nome e foco. Os bugs raramente moram no caso comum, que todo mundo testa e que funciona de primeira. Eles se escondem nos casos de borda, as entradas dos extremos: a lista que chega vazia, a que tem um item só, o número zero, o valor máximo, o negativo que ninguém esperava, o texto em branco. Uma função que calcula a média quebra na lista vazia (divisão por zero). Um laço que compara vizinhos falha na lista de um item. Uma busca binária tem detalhes traiçoeiros nas pontas. O caminho feliz esconde esses problemas porque o programador, orgulhoso do código que rodou com o exemplo bonito, esquece de perguntar: e se vier vazio? e se for só um? e se for o máximo? Testar os extremos de propósito é o que separa o código que parece pronto do código que está pronto.

Uma régua com o caminho comum destacado no meio, tranquilo, e as duas pontas sinalizadas com alertas. Nas pontas aparecem etiquetas: lista vazia, um item só, zero, valor máximo, negativo, texto em branco. Pequenos ícones de inseto (bugs) se escondem justamente nas extremidades, não no meio. — O caso comum, no meio, funciona. Os bugs se escondem nas pontas: vazio, único, zero, máximo, negativo.

A postura defensiva

A programação defensiva é uma mudança de atitude ao escrever código. Em vez de supor que tudo virá perfeito, você assume que o inesperado vai acontecer e se prepara para ele. Antes de dividir, você se pergunta: e se o divisor for zero? Antes de acessar a primeira posição de uma lista, você checa: e se ela estiver vazia? Antes de usar um dado, você valida. Essa postura reúne tudo que este módulo ensinou: as cláusulas de guarda que barram casos ruins na entrada, a validação que não confia no que vem de fora, o tentar/capturar que ampara o que pode dar erro. Não se trata de paranoia, e sim de realismo: no mundo real, listas chegam vazias, usuários digitam bobagens e arquivos somem. Um código defensivo não é maior por excesso de medo; ele é robusto porque encara a realidade de que as coisas dão errado, e decide de antemão o que fazer quando derem.

🎮 Jogo da aula

É um caso de borda?

Para uma função que calcula a média de uma lista de notas, decida se cada entrada é um caso comum ou um caso de borda que merece atenção especial.

Falhar com clareza quando preciso

Nem todo problema tem uma saída elegante, e a programação defensiva inclui saber falhar bem. Quando o programa encontra uma situação que realmente não deveria acontecer, um estado impossível, um dado que passou por todas as validações mas ainda está errado, a pior reação é continuar como se nada fosse, produzindo resultados sem sentido em silêncio. A melhor reação é falhar com clareza: parar, avisar exatamente o que deu errado, e onde. Uma mensagem de erro clara, do tipo esperava uma lista com pelo menos um item, mas recebi uma vazia, vale ouro para quem vai consertar, e é infinitamente melhor que um número absurdo saindo calado ou uma quebra críptica. Falhar alto e claro parece o oposto de robustez, mas é parte dela: um programa robusto trata o esperado com elegância e denuncia o impossível com honestidade, em vez de mascarar o problema e empurrar o estrago para a frente. Com essa mentalidade, você fecha o módulo de robustez pronto para escrever programas em que dá para confiar.

Teste rápido

O que é a programação defensiva?

Perguntas frequentes

O que é um caso de borda?: É uma entrada dos extremos do que o programa aceita: a lista vazia, o único item, o zero, o valor máximo, o negativo, o texto em branco. Bugs se escondem aí porque o programador costuma testar só o caso comum. Testar os extremos de propósito revela problemas que o caminho feliz esconde.
Por que os bugs se escondem nos extremos?: Porque o caso comum é o que todo mundo testa e ajusta até funcionar. Os extremos são fáceis de esquecer: quem lembra de testar a lista vazia ou o valor máximo? E são justamente eles que quebram laços, causam divisões por zero e revelam suposições erradas. Por isso a revisão precisa caçar os extremos.
O que é programação defensiva?: É escrever o código antecipando o que pode dar errado e protegendo-o contra isso: casos de borda, entradas ruins, o inesperado. Em vez de supor que tudo virá perfeito, você assume que listas chegam vazias e usuários digitam bobagens, e decide de antemão como reagir. Reúne guardas, validação e tratamento de exceções.
Programar defensivamente não deixa o código enorme?: Um pouco maior, sim, mas não por medo excessivo, e o ganho compensa de sobra. As checagens defensivas costumam ser poucas linhas no começo das funções (guardas), e evitam quebras e bugs difíceis lá na frente. Um código sem nenhuma defesa é menor, mas frágil: quebra ao primeiro imprevisto do mundo real.
O que significa falhar com clareza?: É, diante de uma situação que realmente não deveria acontecer, parar e avisar exatamente o que deu errado e onde, com uma mensagem clara, em vez de continuar produzindo resultados sem sentido em silêncio. Uma boa mensagem de erro vale ouro para quem conserta e é muito melhor que um resultado absurdo saindo calado.
Falhar com clareza não é o oposto de robustez?: Parece, mas não é. Robustez é tratar o esperado com elegância e denunciar o impossível com honestidade. Mascarar um estado impossível, seguindo em frente calado, é o que gera os piores bugs de lógica. Um programa robusto sabe a hora de tratar e a hora de falhar alto, para o problema ser corrigido em vez de escondido.

Fontes

Seu progresso fica salvo neste aparelho. Assinantes sincronizam entre os aparelhos.

← Validar a entrada: a muralha de defesa Concluir e avançar →