Se o Titanic não foi construído para afundar, então para que se preocupar com avisos de emergência e botes salva-vidas, por exemplo. Mas se acontecer algum problema em seu casco a ponto de entrar mais água do que ele pode suportar, ele irá parar no fundo do oceano, queira você ou não. Então coloque alarmes no barco e botes salva-vidas para todos.
E com o seu software não é diferente. Se uma package no banco ficar inválida, ou se o disco do servidor encher porque alguém esqueceu de monitorar, a sua aplicação irá parar, queira você ou não. E não é o famoso "Erro no sistema. Contacte o administrador" que irá salvar você. Emita um aviso preciso, ou o sistema ficará por horas parado até encontrar qual é o problema.
 |
| A maior catástrofe marítima de todos os tempos. Todo software pode apresentar problemas e esteja preparado quando isso acontecer para não ser mais um Titanic. |
Pode parecer boba a comparação, mas, infelizmente, não são apenas os estagiários, ou programadores juniors que não dão atenção a isso. É comum encontrar aplicações onde o Projeto & Design não detalham como será o tratamento de exceção e, tampouco qual será a política para escrita dos logs. Com isso cada programador trata a sua maneira.
E independente de existir orientações dos arquitetos sobre tratamentos de exceção e logs, existem erros comuns nestes tratamentos, os Antipatterns na manipulação de exceção e logs.
Mas antes de falarmos sobre o que não se deve fazer, vamos comentar sobre o que se espera de um bom código, as boas práticas:
Erros comuns encontrados em códigos Java, os Antipatterns:
Nenhum comentário:
Postar um comentário