Out of the box, ASP.NET MVC3 applications have basic error handling. To see, let’s create an action that will deliberately throw an error.
HomeController.cs:
public ActionResult NoView() // this Action has no view, for testing error handling!
{
return View();
}
Now when we hit /Home/NoView (in our development environment), we get the YSOD because MVC raises an InvalidOperationException, as expected.
In our production environment the error is automatically handled nicely and the /Shared/Error view is shown:
I’m not quite sure how MVC is handling the error in production under the covers, since I am NOT specifying the [HandleError] attribute anywhere. Hmm, wait a second, what’s this?
Global.asax.cs:
public class MvcApplication : System.Web.HttpApplication
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorAttribute());
}
Cool, I just learnt something. The [HandleError] attribute is registered globally when we created a new project. That’s going to make the rest of this blog post easier…
Logging Exceptions
In our development environment, when these exceptions are thrown they appear in the eventlog. But in production, they don’t get put into the eventlog. We need to log them somewhere!
There’s a bucketload of ways to log in ASP.NET – log4net, ELMAH, etc. But I decided I wanted to use one that comes built into ASP.NET – health monitoring.
Heath monitoring
Following the helpful chaps at 4guysfromRolla, we can enable .NET health monitoring by editing our web.config:
<configuration>
<system.web>
<healthMonitoring enabled="true">
<eventMappings>
<clear />
<add name="All Errors" type="System.Web.Management.WebBaseErrorEvent"
startEventCode="0" endEventCode="2147483647" />
</eventMappings>
<providers>
<clear />
<add name="EventLogProvider" type="System.Web.Management.EventLogWebEventProvider" />
</providers>
<rules>
<clear />
<add name="All Errors Default" eventName="All Errors" provider="EventLogProvider"
profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" />
</rules>
</healthMonitoring>
</system.web>
</configuration>
But that’s not enough. For some reason, the ASP.NET MVC [HandleError] attribute (registered globally in Global.ascx.cs, remember) doesn’t invoke the health monitoring features. But thanks to a helpful post by Andrew Wilinski, we can create our own HandleError attribute which will. Create a new class called HandleErrorHm.cs:
/// <seealso cref="http://weblogs.asp.net/awilinsk/archive/2008/12/11/handleerrorattribute-and-health-monitoring.aspx"/>
public class HandleErrorHmAttribute : HandleErrorAttribute
{
public override void OnException(ExceptionContext context)
{
base.OnException(context);
new WebRequestErrorEventMvc("An unhandled exception has occurred.", this, 103005, context.Exception).Raise();
}
}
public class WebRequestErrorEventMvc : WebRequestErrorEvent
{
public WebRequestErrorEventMvc(string message, object eventSource, int eventCode, Exception exception) : base(message, eventSource, eventCode, exception) {}
public WebRequestErrorEventMvc(string message, object eventSource, int eventCode, int eventDetailCode, Exception exception) : base(message, eventSource, eventCode, eventDetailCode, exception) {}
}
And now change our Global.asax.cs to use our attribute instead:
public class MvcApplication : System.Web.HttpApplication
{
public static void RegisterGlobalFilters(GlobalFilterCollection filters)
{
filters.Add(new HandleErrorHmAttribute());
}
Big success!! Our exceptions appear in the eventlog on our production web server.
Logging to a SQL database
Since I’m already using ASP.NET authentication I already have an aspnet_WebEvent_Events table. So if I follow the rest of the 4GuysfromRolla post, I can set it up to log to my existing application database:
<connectionStrings>
<add name="ApplicationServices" connectionString="Data Source=.\sqlexpress;Initial Catalog=Jobs;Integrated Security=True" providerName="System.Data.SqlClient" />
</connectionStrings>
...
<system.web>
<healthMonitoring enabled="true">
<eventMappings>
<clear />
<!-- Log ALL error events -->
<add name="All Errors" type="System.Web.Management.WebBaseErrorEvent" startEventCode="0" endEventCode="2147483647" />
<!-- Log application startup/shutdown events -->
<add name="Application Events" type="System.Web.Management.WebApplicationLifetimeEvent" startEventCode="0" endEventCode="2147483647"/>
</eventMappings>
<providers>
<clear />
<!-- Provide any customized SqlWebEventProvider information here (such as a different connection string name value -->
<add connectionStringName="ApplicationServices" maxEventDetailsLength="1073741823" buffer="false" name="SqlWebEventProvider" type="System.Web.Management.SqlWebEventProvider" />
</providers>
<rules>
<clear />
<add name="All Errors Default" eventName="All Errors" provider="SqlWebEventProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" />
<add name="Application Events Default" eventName="Application Events" provider="SqlWebEventProvider" profile="Default" minInstances="1" maxLimit="Infinite" minInterval="00:00:00" />
</rules>
</healthMonitoring>
And now my errors are logged to my SQL database (although they’re not very readable).
What about 404 errors?
We don’t really want 404 errors to be handled in the same way – we should show the user a “page not found” error page instead of the generic “an error occured” page.
Web.Release.config:
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
<customErrors mode="On" xdt:Transform="Replace">
<error statusCode="404" redirect="/Home/NotFound"/>
</customErrors>
</system.web>
HomeController.cs:
public ActionResult NotFound() // web.config sends 404s here
{
return View();
}
Then in Views/Shared, add a new view called NotFound.cshtml:
@{
ViewBag.Title = "404 Not Found";
}
<h2>@ViewBag.Title</h2>
Sorry, but we couldn't find that page.
Note that in our dev environment it will still show the YSOD for 404s, but in production our users will get redirected correctly.
One final note: if you follow these steps, 404s are NOT logged by health monitoring.
Matt's work blog 