Pecado capital no tratamento de exceções - ”síndrome-do-falou-tudo-e-não-disse-nada”
Olá pessoal, hoje falaremos sobre um pecado capital cometido por muitos desenvolvedores no tratamento de exceções.
Um tratamento de exceções eficiente é aquele que impede que o sistema pare por completo e que nos ajuda a diagnosticar o problema ocorrido e não um que mascare o erro.
Pois bem, apesar desse conceito ser óbvio, não é isso que vemos muitas das vezes. É comum vermos desenvolvedores “tratando” exceções, de forma que acaba atrapalhando a análise do problema ou então mascarando o mau funcionamento do sistema.
Vou mostrar para vocês um erro muito comum e que deve sempre ser evitado no tratamento de exceções.
É o que chamo de ”síndrome-do-falou-tudo-e-não-disse-nada”. É aquela velha história, quando alguém te fala alguma coisa, mas na verdade acaba não dizendo nada, ou seja, você continua com os mesmos questionamentos anteriores ao diálogo.
Essa síndrome se caracteriza pelo seguinte cenário:
try
{
//executa rotina 1
//executa rotina 2
//executa rotina 3
//executa rotina 4
}
catch (Exception E)
{
MessageBox.Show("Ocorreu um erro no programa");
}
Imaginem a situação. O seu cliente te liga e lhe diz :
- “Deu um erro no programa.”
Você pergunta:
- “Qual a mensagem de erro ?“
Ele lhe responde
- “Ocorreu um erro no programa”
Olha que situação. Você sabe que deu um erro no programa, pode até ser que saiba que está entre as rotinas 1,2,3 e 4 mas não faz idéia se foi um erro de conversão, se foi um objeto não criado, se foi um valor muito grande que estourou, enfim, seu programa lhe diz que algo aconteceu mas não te diz nada a respeito do que aconteceu.
Para realizar um tratamento de exceções desse tipo é melhor nem realizar tratamento de exceções, se não tivesse esse “tratamento”, pelo menos você saberia qual a mensagem real de erro que ocorreu e poderia assim investigar, analisar e resolver o problema.
Portanto, sempre que tratar uma exceção, coloque na mensagem ou em algum log, enfim, em algum lugar, o máximo de informações que puder. Como por exemplo, a pilha de execução, a classe que gerou a exceção, mensagem de erro, enfim, o maior número de informações possível que possam te ajudar na análise e solução daquele problema, caso contrário, você saberá que teve um problema mas sua análise do problema ficará bem limitada.
É isso aí pessoal, vamos ficando por aqui, espero que tenham gostado e que as informações passadas sejam úteis no seu dia-a-dia.
E olhem lá hein, vamos caprichar nesse tratamento de exceções rsrs.
Um grande abraço.
Ricardo Coelho.
