Quais são as diretrizes definitivas para tratamento de erros personalizado no ASP.NET MVC 3?

Compartilharei o jeito que acabei fazendo isso, que fazia parte da pergunta original.

Primeiro, os problemas que encontrei:

1. Com customErrors em (ou seja, em produção), o atributo global HandleError engole exceções e renderiza sua visualização de erro, mas você não pode registrá-la com uma ferramenta addon como elmah, pois elmah nunca a vê. Você poderia registrá-lo na sua opinião, suponho, mas é uma visão que parece errada. O atributo global HandleError aparece novo no modelo de projeto do MVC 3 RTM Visual Studio.

2. customErrors com urls para pontos de extremidade do MVC retorna 302 códigos de status. Há a propriedade redirectmode, mas você não pode corresponder URLs mvc em customErrors e usar o modo ResponseRewrite. ( link )

3. Evitar completamente os customErrors e lidar com tudo o que é personalizado no seu aplicativo gera muita complexidade, IMO. (Gostei disto: link , mas não era certo para o nosso projeto)

Minha solução

Eu tirei o MVC da equação completamente. Eu removi o filtro global HandleErrorAttribute em global.asax e foquei inteiramente na configuração customErrors, deslocando-a para usar redirecionamentos WebForm e mudar para redirectmode para ResponseRewrite para evitar os códigos de resposta HTTP 302.

<customErrors mode="On" defaultRedirect="/Error.aspx" redirectMode="ResponseRewrite">
  <error statusCode="404" redirect="/NotFound.aspx" />
</customErrors>

Em seguida, no evento NotFound.aspx page_load, defina o Response.StatusCode para 404 e, em Error.aspx, defina o código 500.

Resultados:

As metas para ambos foram alcançadas com os logs do Elmah, a página de erro amigável e o código de status com uma linha de código no code-behinds. Nós não estamos fazendo o "MVC Way", como a solução anterior faz, mas eu estou bem com isso, se é duas linhas de código.

Acho que o MVC, o ASP e sua estrutura favorita de registro / tratamento de exceções podem lidar com seus objetivos muito bem. O ELMAH e a Enterprise Library fornecem fácil manuseio e registro de exceções, então escolha o seu favorito. Não vou entrar nos prós e contras de cada um aqui.

NOTA: você não pode exibir uma página de erro amigável e retornar um HTTP 404 ou 500 como sua pergunta sugere. Quando você retornar uma página de erro amigável, o código HTTP retornado ao seu navegador será 302. Esse é um redirecionamento para a página de erro amigável.

Páginas de erro amigáveis

Parece que você pode alcançar seus objetivos pelas boas configurações do web.config que fazem parte do ASP.net há algum tempo. Você menciona mostrando informações de depuração quando em dev e mostrando páginas amigáveis em produção. Você pode usar a seção de erros personalizados do web.config para isso (Set CustomErrors="Off" para mostrar informações de depuração). Eu vou assumir que você está familiarizado com o atributo CustomErrors, se não ler isto:

link

Se você precisar de maior granularidade de controle sobre quais exibições de erro você exibe, use o Atributo HandleError do MVC. Desta forma, você pode escolher diferentes vistas de erro para cada ação / controlador.

link

Registro de Exceções

Parece que você deseja responder a todas as suas exceções da mesma forma ("Registre erros e envie-os por e-mail para o administrador em produção"). Se este for o caso, sua opção mais simples é adicionar código a

Application_Error (remetente do objeto, EventArgs e)

no seu global.asax. É aqui que você pode passar para a estrutura de registro escolhida.

Se você quiser mais controle sobre o registro / tratamento de exceções, subclasse HandleErrorAttribute e substitua

OnException(System.Web.Mvc.ExceptionContext filterContext)

este é outro lugar onde você pode passar para a estrutura de registro escolhida.

link

Isso lhe dá mais controle do que a técnica Application_Error mencionada acima.

Em geral, o MVC oferece uma grande granularidade de controle sobre como lidar com erros. Se você não precisa deste controle, então você pode usar as maneiras ASP.net de fazer coisas como definir páginas de erros no seu web.config.