MVC 5: Error Pages - Standard Features
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:
- Decorating the controller actions with the HandleErrorAttribute
- Overriding the OnException method in the controller
- Implementing the Application_Error method in the Global.asax.cs file
- Using the customErrors and httpErrors attributes in the web.config file
We also have our own share of solutions in the Kentico MVC NuGet package:
- Implementing a custom CreateController method
- Implementing a controller/action attribute for handling the HttpNotFoundResult
- Implementing a custom InvokeAction method
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
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
- 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.
- 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
- 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
- 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.
- 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.