MVC3 Error Handling - Insists on using View called 'Error' - asp.net-mvc-3

Question

I have custom error handling defined for my application and it all works wonderfully - when a resource cannot be found, the correct 'NotFound' view renders. When an unhanlded exception occurs, the 'ServerError' view renders.
The problem I am facing is that my application insists on trying to find a View called 'Error' but doesn't find it, as i don't have one and thus this exception gets thrown during my custom error handling routine:
"The view 'Error' or its master was not found or no view engine supports the searched locations. The following locations were searched: ... "
I have an Application_Error event handler which does the logging of all unhandled exceptions:
protected void Application_Error(Object sender, EventArgs e)
{
Exception lastEx = Server.GetLastError();
// Attempt to Log the error
try
{
Utils.Logger.Error(lastEx);
}
catch (Exception loggingEx)
{
// Try and write the original ex to the Trace
Utils.TryTrace(lastEx.Message);
// Try and write the logging exception to the Trace
Utils.TryTrace(loggingEx.Message);
}
}
I have customErrors turned 'On' in my web.config:
<customErrors mode="On" defaultRedirect="blah">
<error statusCode="404" redirect="dee"/>
<error statusCode="500" redirect="blah"/>
</customErrors>
And i have routes defined in my Global.asax.cs RegisterRoutes method which correspond to the Redirect defined in web.config above:
routes.MapRoute(
"Error - 404",
"dee",
new { controller = "Error", action = "NotFound" }
);
routes.MapRoute(
"ServerError", // When this route is matched we want minimal error info displayed
"blah",
new { controller = "Error", action = "ServerError" }
);
I have a BaseController which contains an OnActionExecuted routine:
protected override void OnActionExecuted(ActionExecutedContext filterContext)
{
Logger.Info(String.Format(Constants.LOG_ACTION_EXECUTED, filterContext.Controller.ToString(), filterContext.ActionDescriptor.ActionName));
// Log any exceptions
if (filterContext.Exception != null)
{
Stack<string> messages = new Stack<string>();
Exception current = filterContext.Exception;
messages.Push(current.Message);
while (current.InnerException != null)
{
messages.Push(current.InnerException.Message);
current = current.InnerException;
}
StringBuilder result = new StringBuilder();
while (messages.Count != 0)
{
result.Append(messages.Pop());
string nextline = messages.Count > 0 ? "OUTER EXCEPTION " + messages.Count + ": " : "";
result.Append(Environment.NewLine);
}
Logger.Error(result.ToString());
}
base.OnActionExecuted(filterContext);
}
Is there somewhere else that the Framework defines which view to render in the event of an unhandled exception?
Is my custom error handling routine missing a final step which would ensure that the Framework no longer expects to find the 'Error' view???

Answer 1

You need to remove the HandleErrorAttribute handler in Global.asax.cs file. This attribute sets the view as Error. Then MVC runtime will not handle the exception and exception will propagate to Asp.Net runtime where it will use the customErrors section to display the page.
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute()); // remove this line
}

Answer 2

I had already removed the line which added the filter automatically to all Controllers...as suggested by Eranga - so that wasn't what was causing the Framework to search for the 'Error' view.
The problem i was experiencing was being caused by some left over [HandleError] attribute tags sitting on top of one of my Controllers.
So it is interesting to note that: despite the fact that my controller had the [HandleError] attribute decorated at the top of its class definition, my custom error handling routine, as defined in the web.config, was still being called - and was correctly rendering the required Views...
The framework error handling (as defined by the HandleErrorAttribute) would fail, my Application_Error would catch the Exception and silently log it to the Database via my 'Logger' instance...then my custom error handling routine would complete successfully.