Recently I’ve been a bit surprised to find out that ASP.NET MVC [HandleError] attribute forces your website to bypass the Application_Error event. I wouldn’t normally be concerned about this, but typically Application_Error is your last resort to log errors. Logging is a vital feature of any application and I wouldn’t like to stop using it in favour of the [HandleError] attribute.
Okay some may say, what’s wrong with you, just drop [HandleError] and rely on the web.config and Application_Error error handling. That doesn’t sound a bad idea, but I don’t particularly like it. Why? Because of 2 things:
- [HandleError] is a formal Microsoft way to handle exceptions in ASP.NET MVC
- [HandleError] allows you to have separate error views for every controller (or just for some plus a generic one)
After some research I realised that it does seem to be an unfortunate oversight from Microsoft ASP.NET team, that a default [HandleError] filter doesn’t really allow you to track errors. With some Google help I have found a few suggestions how to overcome the issue, but none of them looked really simple and elegant. I didn’t want to copy/paste/modify/test some large code just to track .NET exceptions.
I reckon I have come up with a better and much simpler solution. All you need to do is to insert a code snippet into your error.aspx file and that code snippet will do logging or whatever else is required:
- ASP.NET MVC3 – Application_Error not firing log4net
- Limiting LINQ String Field Lengths
- Linq to SQL select and update oddity
- Power of the ASP.NET MVC + jquery
- Remote Desktop Connection Manager
Tags: ASP.NET MVC