Better error handling
When trying to handle errors in ASP.NET, you have to jump through a series of unintuitive and often poorly documented hoops to catch an exception and handle it in a sensible way. The non-senisble and default way to handle exceptions would be to redirect to a static HTML file that responds with an HTTP 200 Status Code, which is so wrong it's crazy that it's even available as an option, nonetheless set as the default.
It's also extremely confusing that IIS and ASP.NET each tries to handle errors on their own way, with their own corresponding, diverging and confusing configuration options in web.config. Being able to handle errors in one place, preferably through programmatic means so overrides can take the HTTP context into account and act on it, is not only wanted, but needed.
Please ensure that the error handling story in the next version of ASP.NET and IIS is a good one. The current one is a nightmare.
Alexander Trauzzi commented
I'm going to sound like a broken record here, but see Laravel on this one. They have a really nice global error handler that can be pre-empted with closures and custom classes.
Lachlan B commented
Also completely agree with Asbjørn Ulsberg. Error handling is a mess. Elmah is not a great solution and in some cases just further complicates things. For something that's so vital to any application I can't believe this has so few votes, very disappointing. Who cares about IOC when you can't trap errors simply and easily.
Jonas Gauffin commented
Peter: There is a free alternative, my startup http://onetrueerror.com
I agree with Asbjørn Ulsberg entirely! Handling errors in ASP.NET MVC is extremely confusing and error prone. You're never sure if you have all the right incantations between web.config, IIS, global.asax, controller errors, and... It's just a big mess of legacy code mixed with IIS weirdness and magic. Here's to hoping that vNext is going to fix this.
Unify the many divergent, overlapping and contradicting error handling mechanisms of the ASP/IIS stack would be most helpful. Deprecating and warnign at application compile time would go a long way towards obsoleting and end of life-ing these methods.
Asbjørn Ulsberg commented
Jonas, the redirect solution that exists today shouldn't exist. It breaks the web inn all sorts of ways. Also, any use of "static" is a killer for testing, so that should go as well. "Application_Start" is an abomination and its "HttpApplication" object along with the "OnError" event needs to be seriously revised.
Everything related to ASP.NET that has any backwards compatibility with the old ASP should go and be redone with instance-based, non-static, non-magically "auto-wire-up", clean and intuitive code.
Jonas Gauffin commented
The cleanest solution would probably be if ASP.NET included a custom HTTP module which handles ALL errors. Add a static event to it which can be subscribed to from the Application_Start.
You should probably make sure that the exception is retained over the customErrors redirect so it can be used in the custom error pages.