I suggest you ...

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.

141 votes
Sign in
Password icon
Signed in as (Sign out)
You have left! (?) (thinking…)
Asbjørn Ulsberg shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →


Sign in
Password icon
Signed in as (Sign out)
  • Alexander Trauzzi commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

  • Peter commented  ·   ·  Flag as inappropriate

    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.

  • Anonymous commented  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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  ·   ·  Flag as inappropriate

    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.

Feedback and Knowledge Base