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.
Asbjørn Ulsberg
shared this idea
2 comments
-
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.
