Introdução
Olá Pessoal, nesse meu primeiro artigo sobre desenvolvimento resolvi apresentar uma classe que sempre usei em meus projetos, a classe de rastreamento de erros. O objetivo desse artigo é fazer com que o desenvolvedor não dependa das informações do usuário para detectar onde o problema ocorreu e também estudar os recursos que o asp.net oferece para tratamento de erros.
Vamos aprender como utilizar a instrução try…catch e falar um pouco sobre programação defensiva. Veremos o que a classe de rastreamento faz e como configurar a mesma em seu projeto, e finalmente veremos como funciona a tag customErros do web.config e como configurar seu projeto para apresentar páginas de erro amigáveis.
Utilização do try… catch… finally
A instrução try cacth permite que o desenvolvedor possa gerenciar possíveis exceções em seu código fazendo com que a exceção possa ser tratada em tempo de execução de uma forma amigável.
O código acima mostra como utilizarmos a instrução em questão:
try: Nesse ponto você insere o seu código passível de erro.
catch (FileNotFoundException e): Caso o código do try dispare uma exceção do tipo entre as chaves, o trecho será executado.
catch (Exception e): A classe Exception é a mais genérica entre as classes de exceções do .net, logo, a mesma deve ser sempre a última na lista de catchs.
finally: Esse trecho é sempre executado, não importando se houve ou não erros durante a execução. Uma dica é utilizar esse trecho para liberar recursos utilizados pelo seu código, Ex.: Fechar conexões.
Dica -> Procure não disparar nos seus códigos exceções do tipo Exception, use sempre que possível uma exceção específica para o tipo do erro.
Você também pode usar o try…catch de forma aninhada como mostra a imagem à baixo:
Use sempre o try…catch em códigos suscetíveis a erros (ou seja, quase todos). Dessa forma você poderá instruir o usuário com uma mensagem mais específica para o problema que aconteceu.
Programação defensiva
Programação defensiva é um padrão de desenvolvimento que tem a Lei de Murph como uma preocupação constante. Programadores que utilizam esse padrão escrevem seus códigos tentando prever todos os erros antes que os mesmos aconteçam. Esse padrão aumenta a qualidade e a segurança do projeto como um todo.
Sou totalmente a favor desse padrão, e se tivéssemos mais adeptos os projetos de software teriam uma qualidade bem superior à atual no mercado.
Classe de rastreamento
A classe de rastreamento é uma ferramenta desenvolvida com o seguinte propósito: Armazenar todos os dados possíveis sobre a exceção para que o desenvolvedor possa rapidamente descobrir a causa da mesma e tomar as medidas de correção.
Como o código é relativamente simples, não vou posta-lo por motivos de espaço, porém, você poderá fazer o download do projeto de exemplo no final do artigo.
A classe Rastreamento possui 4 métodos privados e 1 método público:
Rastreamento.RastrearSessao: Método privado responsável por coletar todos os dados da sessão corrente.
Rastreamento.RastrearCookies: Método privado responsável por coletar todos os dados dos cookies escritos pela aplicação.
Rastreamento.RastrearServidor: Método privado responsável por coletar o valor de todas as variáveis de servidor.
Rastreamento.RastrearFormulario: Método privado responsável por coletar todos os dados que foram enviados pelo cliente via Post.
Rastreamento.RastrearExcecao: Método público que monta um relatório texto que irá contar as informações da exceções, e os dados referentes aos métodos anteriores. Esse método que será invocado para rastrearmos nossas exceções.
Para utilizar a classe em seu projeto, basta copiar a mesma para dentro da pasta App_Code.
Dica -> Você pode personalizar a classe para armazenar o relatório onde quiser, o projeto de exemplo guarda o relatório num arquivo texto, porém, o mesmo pode ser enviado por e-mail, para um sgbd, etc.
Application_Error
Para utilizar a classe de rastreamento de forma genérica é muito fácil, basta adicionar o arquivo Global.asax na pasta raiz do seu projeto e configurar o evento Application_Error como mostra a imagem:
O evento Application_Error é disparado sempre que ocorre um erro não tratado na aplicação, logo, é só pegar o último erro ocorrido e passar a exceção para o método de rastreamento.
Nesse ponto, você terá configurado seu projeto para dar um feedback de cada exceção não tratada, porém, isso ajuda somente o desenvolvedor, não é nada agradável para o usuário se deparar com a “tela amarela” do asp.net, então vou abordar como configurar páginas amigáveis de erro.
Dica -> Pratique programação defensiva, trate o maior número de erros possíveis antes de disponibilizar o projeto. Não é bonito quando o cliente se depara com uma tela de erro a cada 3 cliques.
Tag customErrors do web.config
O Asp.net oferece recursos para que possamos configurar rapidamente uma página de erros amigável para os usuários da aplicação. Veja a imagem a seguir:
Adicionando a tag customErrors na sessão system.web do web.config podemos realizar as seguintes configurações:
defaultRedirect: Página que será exibida quando uma exceção não tratado for disparada.
mode: Atributo que configura como os redirecionamentos vão funcionar. On Sempre redireciona, Off Nunca redireciona RemoteOnly redireciona quando o usuário estiver usando um endereço diferente de localhost para acessar a aplicação.
Você também pode configurar páginas de erro personalizadas para código de erro existente.
Veja o funcionamento das configurações vistas no projeto de exemplo no final do artigo.
Conclusão
De forma muito prática é possível se ter um feedback da aplicação sobre suas exceções e também poupar o usuário de “telas amarelas”, não disponibilizo nenhum projeto sem esses recursos.
Espero que tenham gostado da minha visão sobre tratamento de erros.
Estamos aí para qualquer dúvida ou sugestão!
Abraços,
Denis Ferrari
Download do projeto de exemplo.
