Estamos sendo bombardeados - cada dia mais - com noticias sobre falhas descobertas neste ou naquele software, as quais permitem que a gente "hackers" provocarem os mais variados incidentes de seguranca. Mas, afinal, o que sao estas falhas?Quando profissionais da area de informatica sentem uma inclinacao para o ramo da programacao, eles devem descobrir se possuem determinados vicios de raciocinio logico imprescindiveis para a tarefa, e uma dessas qualificacoes e o exercicio de "pensar o impensavel", sempre fugir do padrao e analisar seriamente as excecoes. Infelizmente nem todos dao o devido valor a isso.A partir de agora vamos analisar um exemplo extremamente simplificado e descobrir porque administrar excecoes e fundamental na seguranca de um software.Imagine uma rotina que verifique a senha de um usuario antes de liberar seu acesso a um sistema qualquer. Ela seria, a muito grosso modo, assim:1a instrucao: Pedir senha de 4 numeros ao usuario - usuario digita a senha.2a instrucao: Se os 4 numeros forem iguais a senha cadastrada, siga para 3a instrucao.Se os 4 numeros forem diferentes, negar acesso. Fim do programa.3a instrucao: Liberar seu acesso. Fim do programa.Esta e uma rotina simples que funciona muito bem, desde que o usuario obedeca a primeira instrucao e digite sua senha de forma correta. Entretanto, e com relacao a desobediencia que se da a importancia de trabalhar com as excecoes.Vamos supor que o usuario nao forneca os dados conforme o programa espera. Por exemplo, ao inves de numeros, ele digite 4 letras. Quando o programa chegar a 2a instrucao, o computador vai tentar colocar as letras em uma memoria que esta preparada para receber apenas numeros, e isto pode provocar um erro que invalidaria toda a 2a instrucao. Ao dar continuidade, o acesso estaria liberado na 3a instrucao independente da senha digitada, desde que nao fossem 4 numeros.O exemplo acima foi bem simplificado para facilitar o entendimento mas a ideia geral por tras das falhas de software e essa: rotinas mal projetadas que nao preveem todas as acoes dos usuarios (ou de outras partes do programa). Uma correcao para o problema exposto seria uma alteracao logica na filosofia de comparacao. Veja:1a instrucao: Pedir senha de 4 numeros ao usuario - usuario digita a senha.2a instrucao: Se os 4 numeros forem diferentes da senha cadastrada, siga para 3a instrucao.Se os 4 numeros forem iguais, liberar acesso. Fim do programa.3a instrucao: Negar seu acesso. Fim do programa.Com esta alteracao, qualquer que fosse o erro provocado pela entrada incorreta de dados resultaria na negacao do acesso, uma vez que um erro na 2a instrucao eliminaria a comparacao juntamente com a decisao de liberar o acesso do usuario.Obviamente, este tipo de problema nao esta limitado a situacoes de verificacao de senhas, muito pelo contrario, ele se espalha pelas rotinas que nao recebem muita atencao com relacao a seguranca, como por exemplo, rotinas de verificacao de datas, classificacao de dados e principalmente aquelas que recebem dados de outros programas.Rotinas que sao feitas para se comunicar - remotamente - com outras rotinas sao as que apresentam as maiores falhas pois, ao construirem estes programas, nao