Compartilharei o jeito que acabei fazendo isso, que fazia parte da pergunta original.
Primeiro, os problemas que encontrei:
-
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. -
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 )
-
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.