tl/dr Trying to comprehensively handle errors with IIS and MVC is such an impossible dance that it requires one to metaphorically lick the back of one knees whilst riding a unicycle, juggling handleless chainsaws

Web Severs

Usage share of web servers (Source Netcraft)CC BY-SA 3.0

So it's 2014 2015, Microsoft's IIS market share is still gaining on apache, OWIN is gaining popularity and you still can't handle errors properly in MVC 5.x

I'm not talking about your average action filter or httpresult either.

public ActionResult Bad(){
	throw new MichaelJacksonException("because I'm bad!");

public ActionResult Thriller() {
	return new HttpError("Something evil's lurkin in the dark");

A quick survey over the many..many...many...many topics on stackoveflow reassures me that I am far from the only one who has wrestled with this particular silverback of a guerrilla (sic)
So many upvoted answers all claiming to be 'the one'. If you aren't familiar with just what I vipers nest this issue is, take some time to read the posts below so you can get a sense of how confused the situation all is.

Of octopi and string bags


I've lost count of how many times and how many hours I've poured over the posts above, implementing and reimplementing each solution only to find that it is akin to putting a octopus in a string bag. As soon as you put one arm in, another get loose.

You do this long enough and it drives you slightly crazy.

Why so serious?


So what are my criteria thats so demanding?

  • Errors in all forms, should return http status codes between 4xx and 5xx
  • Errors on my application should be logged in some way
  • Errors should display a customised page for my application
  • Errors should not cause the url to be changed/rewritten
  • Error configuration should be all contained within the application for easy deployment

that's it, nothing hard about that right?

Well it should be easy, but it isn't. I hope MVC 6 has a better story to tell.