On my todo list for today, I had a entry for building a error handling mechanism in my MVC application that would write errors to a central location and send me notifications when they occurred. I had a vague idea of how I could accomplish this. One thought was creating an exception filter and logging the errors to a SQL table for later review. Therefore, I started doing some research. I figured I would have to read some MSDN documentation and perhaps a few blog articles to make sure I had a good grasp on what technologies to use to build a proper solution. Luckily, while I was searching Google for "MVC error handling" I stumbled across ELMAH. 5 minutes later I had ELMAH fully implemented and running on my site! Yes, it is that easy.
Just for background, ELMAH (Error Logging Modules and Handlers) is an application-wide error logging facility that is completely pluggable. It can be dynamically added to a running ASP.NET web application, or even all ASP.NET web applications on a machine, without any need for re-compilation or re-deployment.
Once ELMAH has been dropped into a running web application and configured appropriately, you get the following facilities without changing a single line of your code:
- Logging of nearly all unhandled exceptions.
- A web page to remotely view the entire log of recoded exceptions.
- A web page to remotely view the full details of any one logged exception.
- In many cases, you can review the original yellow screen of death that ASP.NET generated for a given exception, even with customErrors mode turned off.
- An e-mail notification of each error at the time it occurs.
- An RSS feed of the last 15 errors from the log.
Sounds great! So, how do you get this running in your MVC app. Well here are the steps (Taken almost in verbatim from the ELMAH Wiki page http://code.google.com/p/elmah/wiki/MVC) :
- Download the latest binaries from http://code.google.com/p/elmah/downloads/list and add a reference to the ELMAH.dll assembly.
- Edit your web.config file to call ELMAH
- First add the following code to your <configSections> to make ELMAH read it’s configuration from web.config:
<sectionGroup name="elmah">
<section name="security" requirePermission="false" type="Elmah.SecuritySectionHandler, Elmah" />
<section name="errorLog" requirePermission="false" type="Elmah.ErrorLogSectionHandler, Elmah" />
<section name="errorMail" requirePermission="false" type="Elmah.ErrorMailSectionHandler, Elmah" />
<section name="errorFilter" requirePermission="false" type="Elmah.ErrorFilterSectionHandler, Elmah" />
</sectionGroup>
- Add this block to your section to add the elmah file handler. This will reroute all requests to a file called elmah.axd to the ELMAH error-overview page. So when you want to look at the list of errors you’ll access http://server/elmah.axd. The name doesn’t matter, feel free to rename it, but be aware that the extension has to be mapped to the ASP.NET pipeline inside IIS (so naming it .html wouldn’t work if not configured correctly).
<add verb="POST,GET,HEAD" path="elmah.axd" type="Elmah.ErrorLogPageFactory, Elmah" />
- At last add the ELMAH logging module to your section:
<add name="ErrorLog" type="Elmah.ErrorLogModule, Elmah"/>
- Configure where you want the errors to be logged. If you want to log to XML files add this line in your web.config
<elmah>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
</elmah>
- Finally, configure the routing. Up until now we were 100% true to the normal configuration routine for normal ASP.NET applications, there is only one slight adjustment to making it work in MVC.
You need to allow the requests to the ELMAH front-end (elmah.axd in this example) to pass through the MVC routing logic unchanged so that it gets handled by normal ASP.NET behind MVC. This is as trivial as adding an ignore route to your routing table in Global.asax.cs:
public static void RegisterRoutes(RouteCollection routes)
{
routes.IgnoreRoute("elmah.axd");
Now ELMAH is installed. So now its time to test it out. This can be done by throwing an exception in one of your controllers. Just for simplicity, I added the line throw new exception("testing ELMAH") in the Index Method of my default controller. When the exception is thrown it is written to an XML (could also be a Oracle, Access or SQL database). Then by accessing http://server/elmah.axd you can view the errors remotely:

All of this functionality is yours, for free, thanks to ELMAH.