Início > Qualidade de Código > Boas Práticas no uso de Exceções

Boas Práticas no uso de Exceções

AtrExceção Null Referenceavés da manipulação de exceção podemos tratar situações indesejadas que podem acontecer durante a execução de um código. Nesse post, vamos discutir sobre algumas práticas para melhor utilizar esse recurso em nossos códigos.

Primeiramente, exceções não devem ser usadas para controlar o fluxo da aplicação, como se fosse uma estrutura if-then-else. Veja o exemplo abaixo:

IManager manager;
try
{
manager = businessManagerRepository.GetManager(managerId);
//Lógica para o Gerente de Negócio
}
catch(BusinessManagerNotFoundException ex)
{
manager = projectManagerRepository.GetManager(managerId);
//Lógica para o Gerente de Projetos
}

A estrutura try-catch não deve ser usada como meio de escolha do caminho a ser tomado segundo o levantamento de uma exceção.

Outra boa prática é diferenciar as exceções de sistemas das exceções de negócio. Ao serem lançadas exceções de negócio devem permitir que o usuário refaça a operação. Geralmente elas são exceções personalizadas, inerentes ao domínio da aplicação.

No caso de exceções de sistema, é importante adicioná-la ao log e verificar se ela foi gerada por uma falha no processo de comunicação com algum serviço, como o banco de dados por exemplo. Esse tipo de exceção pode gerar um estado inconsistente da aplicação. Dessa forma, é necessário voltar ao estado correto (ou até mesmo ao estado inicial) garantindo que as operações futuras não sofram alterações de comportamento devido ao erro ocorrido.

Nos dois casos, sempre exiba uma mensagem amigável ao usuário. Mensagens como “Ocorreu um erro durante o cadastro do cliente” são muito melhores que “Null Reference exception on line 25”.

Outra técnica importante é apenas capturar exceções são “esperadas”. Veja o exemplo:

try
{
this.SendMessageToCustomer(message);
}
catch(Exception ex)
{
//tratamento da exceção
//...
errorMessage = "Não foi possível enviar a mensagem";
}

O código captura uma exceção do tipo Exception. Esse é um tipo muito genérico e pode acabar encobrindo de forma indesejada algum erro na aplicação (principalmente se um log não estiver sendo utilizado). No exemplo acima, pode ter ocorrido um erro no formato da mensagem, ou na conexão com o servidor de email ou outra falha qualquer. Em ambos os casos, não será possível rastrear a verdadeira causa do levantamento da exceção.

O melhor nesse caso é capturar uma exceção mais especializada. Se nenhuma exceção já existente servir para esse caso, crie uma que possua essa responsabilidade. O código ficaria assim:

try
{
this.SendMessageToCustomer(message);
}
catch(CanNotConnectToEmailServerException ex)
{
//tratamento da exceção
//...
errorMessage = "Não foi possível enviar a mensagem. Ocorreu um erro na conexão com o Servidor de Email.";
}

Lembre-se que o framework já possui exceções para diversas situações diferentes. Utilize-as sempre que puder, para não reinventar a roda.

Anúncios
  1. Nenhum comentário ainda.
  1. No trackbacks yet.

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: