MVC 5: Error Pages - Standard Features

JanL@kentico.com[email protected] Czech RepublicMember, Administrator, Kentico Staff admin
edited February 2017 in Back-end Development

What would be your approach to easily display error pages in MVC 5 projects?

There are numerous approaches mentioned all over the web. They could be summarized in the following way:

We also have our own share of solutions in the Kentico MVC NuGet package:

Let's dig in a little more detail to see which would suit you well.

In this post, I'll describe the first group of methods (the standard methods in the first bullet list).

In another post I'll propose a simple error handling solution based on these standards.

For the second bullet list, you can navigate to MVC 5: Error Pages - Advanced Logic

The HandleErrorAttribute

It is built in the framework as the most declarative and brief way of catching exceptions. Literally a declarative try/catch. You can decorate a controller action, specify a type of an exception and point to a view:

[HandleError(ExceptionType = typeof(HttpException), View = "Error")]

Pros: You can set different error views for each individual controller action

Cons:

  • You cannot write any decision logic of your own
  • You cannot specify a RouteData object to pass to the view
  • Only exceptions raised within the action's call stack are being trapped

The OnException method

This built-in IExceptionFilter.OnException method can be overridden in your controller to handle exceptions in an imperative way.

Pros:

  • You can have your own logic
  • You can have a strongly-typed error view (views) and pass RouteData to it

Cons: As above, only exceptions raised within the action's call stack can be trapped

The Application_Error method

This method in Global.asax.cs can be used to handle all exceptions originating from within the ASP.NET assemblies. Its corresponding event is raised after the above two exception handling mechanisms finish their jobs.

Pros: Broader scope of exceptions, not just from within MVC

Cons:

  • You cannot redirect to a view, you need to use good old .aspx pages or use hard-coded URLs to the error view (views) eventually
  • Exceptions from static file requests (and other IIS modules outside of ASP.NET) cannot be handled

The customErrors and httpErrors attributes

The customErrors web.config attribute can be called an older alternative to the above HandleErrorAttribute. It was designed before MVC came out.

With this technique, you can specify a HTTP status code and its corresponding URL:

<error statusCode="403" redirect="~/NotAuthorized"/>

Pros: A more declarative alternative to the Application_Error method, if simplicity is what's needed

Cons:

  • IIS redirects to the URLs with the 302 status code
  • Requires you to point to physical .aspx error pages
  • As above, requests mapped to outside of the ASP.NET assemblies are not handled
  • Handles just HTTP status codes, not any other exceptions

The httpErrors attribute is IIS-scoped, not just ASP.NET-scoped.

Pros: IIS-scoped

Cons:

  • No way of leveraging the ASP.NET or even MVC way of displaying error pages
  • As above, handles just HTTP status codes

Questions to discuss

Error handling in MVC 5 is a huge topic with lots of questions. Let's pick a few:

  • How much time and effort do you invest in handling errors in your projects?
  • Do you develop your own error-handling functionality?
  • If so, in what extent does it differ among projects?
  • Do you use the HandleErrorAttribute often?
  • Do you use the Application_Error method? What kind of exceptions does this method handle in your projects?

Feel free to discuss the topic here! We'd love to hear if this is what you'd use in your projects. Then, we could write an article and discuss how we can improve the Deliver .NET SDK, together with the community.

Sign In or Register to comment.