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.

67 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    Asbjørn UlsbergAsbjørn Ulsberg shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • PeterPeter 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 UlsbergAsbjø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 GauffinJonas 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