HandleError attribute (MVC)

    In ASP.NET MVC you can decorate the action methods and the controllers with filter attributes to control their behavior.  These filters are injected into the pipeline, and depending on their type; they are executed before/after something happens. You can either use the filters that come with the framework, or write your own filters. Even though it is easy to test the functionality of the filters, it may not be easy to test if the controller/action is/are decorated with the filter (You can use reflection).  There are 4 different types of filters that come with the framework:

  • Authorization Filter: These type of filters have very high priority, and run before other types of filters or the action execution.
  • Action Filter: These type of filters have normal priority, and run before and after the action execution, by this way you can do some work before  an action is executed or after an action is executed. A good example could be logging the system activity, or calculating the time that takes to execute the action.
  • Result Filter: These type of filters have  normal priority, and run before and after the action result is executed, by this way, you can manipulate the action results.
  • Exception Filter: These filters are executed if an unhandled exception is thrown.

In this blog posting I will be explaining HandleError attribute which is a type of Exception Filter. You may want to use this filter to catch the exception for either logging the exception to a log file or display a nice error page so the user does not freak out.  If you create a default MVC project using Visual Studio, you will see that the HomeController class is decorated with HandleError filter.

public class HomeController : Controller

This means whenever there is an exception that is not handled, render the Error view, so when there is an exception the framework will first look at the folder “Views/Home” and check if there is an Error.aspx page (assuming you are using the default WebForms Engine). If it can not find this page, it will check if there is a Error.ascx page, if there is none, then the same search will be applied to Shared folder. Finally if there is an Error.aspx/ascx page found it will be rendered, otherwise, in the production system, IIS will handle error, in the development system you may see the error below (depending on your web.config customErrors setting).


Or if you use the HandleError filter, and configure your system right, this may be the screen:


Of course you want to the second user friendly error page. Let’s first see what we should be doing to get the simple user friendly user page and then we will look into customizing this error page.

  1. Decorate the controller or the action method with HandleError
  2. Create an Error.aspx or Error.ascx page, and put this page either into the View folder of the controller or Shared folder.
  3. Open your web.config file and change the custom errors definition to customErrors mode=”On”

After this 3 simple steps, you have  an Error page that will be displayed whenever there is an unhandled exception.

HandleErrorAttribute is defined in the HandlErrorAttributed.cs (suprised?) file. It is a relatively simple and short code. If you check the source code, you will see that there are parameters you can customize.  Here are the list of the parameters that you can customize:

  • View: You can define a new View besides the Error to render for the error message. If you don’t specify a View name, default View name is Error
  • Master: You can define a master page for the View that will be rendered. If you don’t specify a master name, that it is empty by default, which means it will use the default master page.
  • ExceptionType: The exception type that you want to handle, by default it is the very generic System.Exception which means catch all the exceptions.

Note that there is another field you can customize however it is not a direct member of this class, but it comes with inheritance. 
Going back to our example, if we want to change error page name to let’s say “UnderMaintenance” , simple change your filter decoration to:

public class HomeController : Controller

Or if you want to change the master page to Maintenance simply change your filter decoration to:

[HandleError(View="UnderMaintenance", Master="Maintenance")]
public class HomeController : Controller

Now let’s assume you want to redirect the user to different pages for different types of exceptions, then you have to use the ExceptionType property.

  • If the View you are trying to render is not found, then InvalidOperationException will be thrown.
  • If you are trying to connect to SqlServer, and there is an error, then System.Data.SqlClient.SqlException will be thrown

For other types of exception you can check MSDN, but let’s now concentrate on these 2 exceptions, and create 2 different error pages for 2 different types of Exceptions. Here is the right decoration for this goal:

[HandleError(View="Error", ExceptionType=typeof(InvalidOperationException))
typeof(System.Data.SqlClient.SqlException)) public class HomeController: Controller

By this declaration we are telling the system that when there is an InvalidOperationException render the Error.aspx/ascx, when there is a SqlException  error, render DatabaseError.aspx/ascx view.

What happens when we add another HandleError that handles the SystemException which is basically all the exceptions, so if our declaration is like below, and assume SqlException is thrown:

[HandleError(ExceptionType = typeof(SystemException))]
 public class HomeController : Controller

The framework will call  the all filters that can catch this type of exception, in this case, framework will call handlerror twice, one for the SqlException, and one for the SystemException.

You can write your own HandleError filter, and apply it to the controller or action. Inside this filter, you have to set the ExceptionHandled flag to true, so that framework won’t throw the yellow dead screen. If there are more than 1 filter that can catch the error message, all of them have to set the ExceptionHandled flag to true, or framework will throw the yellow dead screen.
The default HandleError attribute also creates a model for your view incase you want to get more information about the error, if you change your error page’s model to HandleErrorInfo, then you can get more information from the framework about the error. A simple example for the Error.aspx could be:

<%@ Page ..  Inherits="System.Web.Mvc.ViewPage<HandleErrorInfo>" %>
Sorry for the error, We are working hard on it to fix the problem.
    <li>Action: <%=Model.ActionName %></li>
    <li>Controller: <%=Model.ControllerName %></li>
    <li><%=Model.Exception.ToString() %></li>


Of course in the real work application, you don’t want to display this information to your user, but you can use this information to write a log to your log system.
Hopefully this article help you to understand HandleError attribute.

May the force be with you.

Tags: , , ,

E-mail | Permalink | Trackback | Post RSSRSS comment feed 0 Responses

Add comment