Tratamento de erros: Tratando e registrando erros

Nesse artigo vou falar sobre o tratamento de erros e registro dos mesmos. Anteriormente escrevi outros artigos sobre o object Exception e o tratamento de erros no .Net :

http://br1dev.blogspot.com/2007/04/tratamento-de-erros-objeto-exception.html
http://br1dev.blogspot.com/2007/04/tratamento-de-erros-objeto-exception_10.html
http://br1dev.blogspot.com/2007/04/tratamento-de-erros-objeto-exception_16.html

Agora vamos ao artigo:

Um fator que melhora a confiabilidade da sua aplicação é a maneira com ela trata os erros que ocorrem durante sua execução. É claro que o ideal é evitar o máximo possível que erros ocorram, mas é necessário que a aplicação se recupere adequadamente quando um erro ocorrer. Achar que sua aplicação está segura e não terá erros, e por isso abrir mão de um tratamento adequado, pode expor sua aplicaçõe a riscos de segurança e integridade da aplicação.

Sempre que um erro ocorrer na aplicação, são importantes os seguintes procedimentos:

• Recuperar o sistema - Sempre que possível, o sistema deve retornar ao estado em que estava antes da execução da operação que gerou o erro. Um exemplo clássico disso. Você confirma o recebimento de uma pedido de venda. A operação atualiza o estoque , mas quando tenta alterar o status do pedido , ocorre um erro. Se o estoque não for retornado ao estado anterior, o usuário pode tentar repetir a operação (Afinal , para ele houve um erro e a operação não foi concluída) e o estoque será alterado novamente, ficando com valores errados.
• Informar o usuário - Evite esconder um erro, não mostrando ao usuário que houve um erro. Exceto em casos específicos, é sempre importante avisar o usuário que o sistema não se comportou da forma esperada, para que ele possa corrigir o problema ou pelos contatar o suporte. Entretanto, uma mensagem do tipo "Object reference not set to an instance of an object" não ajuda em nada o usuário. O ideal é mostrar ao usuário uma mensagem padrão, do tipo "Ocorreu um erro no sistema, contato o suporte técnico etc.", ou então alguma coisa que realmente o ajude a solucionar o problema.
• Registrar o erro - Se por um lado não é interessante mostrar ao usuário detalhes do erro, também não é uma boa ignorar esses detalhes por completo. O ideal é registrar a mensagem original do erro, e todos os outros detalhes possíveis a fim de auxiliar a correção do erro pelos desenvolvedores. Devem ser registradas informações como a pilha de chamadas, que mostra toda a cadeia de chamada de métodos até chegar no local do erro, o nome do erro (ArgumentException, por exemplo) e quaisquer outras informações que estejam disponíveis. Você sabia que com o objeto SQLExcetion é possível obter as mesmas informações que aparecem quando você executa a procedure ou comando no Query Analyzer?. Outra informação importante é a InnerException. No terceiro artigo que mencionei no começa desse post falo mais sobre ela. Para registrar o erro você poderia gravar em um arquivo texto, um arquivo XML, enviar por email ou gravar em um banco de dados. O importante é escolher o mecanismo que torne mais fácil o acesso a essas informações.

Pra finalizar, você poderia tornar esse tratamento mais fácil criando uma função que recebe o objeto Exception e faça o registro e exibição da mensagem referente ao mesmo. Aí, é só chamar a função em todo bloco catch da aplicação.