Desde as primeiras versões do ASP.NET MVC, a Microsoft criou um atributo chamado HandleErrorAttribute, que nada mais do que um filtro (de exceção) e tem a finalidade de interceptar todas as exceções que não são tratadas pelas ações “in-place”. E este filtro pode ser aplicado em nível de ação, de controller ou globalmente, no arquivo Global.asax e, este último nível, já vem configurado por padrão nos projetos ASP.NET MVC.
Este atributo garante com que qualquer exceção não seja exibida no navegador, apresentando aquela tela com detalhes do erro e que o usuário final dificilmente entende. Em sua configuração padrão, quando este atributo é acionado, ele redireciona o usuário para uma view chamada Error. Mas tanto o acionamento quanto a view a ser exibida pode ser customizada em qualquer nível, recorrendo às propriedades ExceptionType e View, conforme é mostrado no trecho de código abaixo. É importante dizer que este atributo pode ser decorado múltiplas vezes, possibilitando a seleção da view de acordo com a exceção que foi disparada.
[HandleError(ExceptionType = typeof(DivideByZeroException), View = “DivideByZeroException”)]
public class SiteController : Controller { }
Simplesmente o fato de existir este atributo decorado na ação, na classe ou globalmente, não é suficiente para acioná-lo, a não ser que configuremos a seção de customErrors no arquivo Web.Config. Esta seção está presente desde a primeira versão do ASP.NET, e agora pode e deve ser usada em conjunto com o atributo HandleErrorAttribute para garantir ou não o redirecionamento do usuário para a view desejada. A configuração mínima para o correto funcionamento deste atributo deve ser:
<configuration>
<system.web>
<customErrors mode=”On” />
</system.web>
</configuration>
E uma vez que o atributo é adicionado, o ASP.NET passará a redirecionar o usuário para a view que exibirá a mensagem amigável. Só que além disso, o ASP.NET MVC faz captura o controller, da ação e da exceção que foi disparada, e configura a instância da classe HandleErrorInfo com todas essas informações referente ao erro que ocorreu, e a adiciona na propriedade ViewData da view que será exibida. Isso irá permitir capturar as informações para exibir na tela caso seja necessário informar ao usuário os detalhes do erro que ocorreu.
@model System.Web.Mvc.HandleErrorInfo
<html>
<head>
<title>Error</title>
</head>
<body>
DivideByZeroException
Controller: @Model.ControllerName
Action: @Model.ActionName
Exception: @Model.Exception.GetType().FullName
Message: @Model.Exception.Message
</body>
</html>
É importante mencionar que o atributo HandlerErrorAttribute somente é acionado, por padrão, quando há erros de número 500 do HTTP. Para outros casos, como 401 (Unauthorized), ele não é acionado e, consequentemente, o erro é exibido para o usuário. Para garantir que seja apresentado, também de forma amigável, outros erros que não sejam do tipo 500, podemos recorrer ao customErrors especificando o erro e a respectiva página de erro que deve ser apresentada quando o mesmo ocorrer.
<customErrors mode=”On”>
<error statusCode=”401″ redirect=”/401.htm” />
<error statusCode=”404″ redirect=”/404.htm” />
</customErrors>
Para finalizar, é importante se atentar em casos onde uma determinada ação (que faz uso deste atributo) é utilizada também por uma aplicação Javascript, pois quando um erro ocorrer, neste cenário o que o cliente está esperando é uma mensagem do erro e não um redirecionamento para uma view. A ideia é que o erro seja tratado pelo próprio cliente (Javascript), que exibirá alguma informação para informar o erro. Uma opção aqui seria herdar da classe HandleErrorAttribute e avaliar se a ação está ou não sendo invocada por uma aplicação Javascript, e para isso, podemos recorrer ao header X-Requested-With, verificando se é igual à XMLHttpRequest, retornando um objeto do tipo JsonResult devidamente configurado.
Israel Aece 