Exception Filters in MVC

Introduction

Exceptions are part and parcel of an application. They are a boon and a ban for an application too. Isn't it? This would be controversial, for developers, it helps them track minor and major defects in an application and sometimes they are frustrated when it lets users land on the Yellow screen of death each time. This would make the users mundane to the application. Thus to avoid this, developers handle the exceptions. But still, sometimes there are a few unhandled exceptions.

Now what is to be done for them? MVC provides us with built-in "Exception Filters" which we will explain here.

CC: Google

Let's start!

A Yellow Screen of Death can be said to be a wardrobe malfunction of our application.

Get Started

Exception filters run when some of the exceptions are unhandled and thrown from an invoked action. The reason for the exception can be anything and so is the source of the exception.

Creating an Exception Filter

Custom Exception Filters must implement the built-in IExceptionFilter interface. The interface looks as in the following.

public interface IExceptionFilter
{
    void OnException(ExceptionContext filterContext);
}

Whenever an unhandled exception is encountered, the OnException method gets invoked. The parameter as we can see, ExceptionContext is derived from the ControllerContext and has several built-in properties that can be used to get the information about the request causing the exception. Their property's ExceptionContext passes are shown in the following table:

Name	Type	Detail
Result	ActionResult	The result returned by the action being invoked.
Exception	Exception	The unhandled exceptions are caused by the actions in the applications.
ExceptionHandled	BOOL	This is a very handy property that returns a bool value (true/false) based on whether the exception is handled by any of the filters in the application or not.

The exception being thrown from the action is detailed by the Exception property and once handled (if), then the property ExceptionHandled can be toggled, so that the other filters would know if the exception has been already handled and cancel the other filter requests to handle. The problem is that if the exceptions are not handled, then the default MVC behavior shows the dreaded yellow screen of death. To the users, that makes a very impression on the users, and more importantly, it exposes the application's handy and secure information to the outside world that may have hackers and then the application gets into the road to hell. Thus, the exceptions need to be dealt with very carefully. Let's show one small custom exception filter. This filter can be stored inside the Filters folder in the web project of the solution. Let's add a file/class called CustomExceptionFilter.cs.

public class CustomExceptionFilter : FilterAttribute, IExceptionFilter
{
    public void OnException(ExceptionContext filterContext)
    {
        if (!filterContext.ExceptionHandled && filterContext.Exception is NullReferenceException)
        {
            filterContext.Result = new RedirectResult("customErrorPage.html");
            filterContext.ExceptionHandled = true;
        }
    }
}

Now let us understand what this does. As we can see, this implements the interface as said earlier and thus implements the method, OnException. This method has the parameter ExceptionContext, the properties of which are specified in the table. In this custom filter, we have handled the most common and neglected exception "Null Reference Exception" that arises when a value returning null is not handled/checked and used in further implementations. The custom filter derives the FilterAttribute to be used as an Attribute over the action or the controller directly like [CustomExceptionFilter]. In this implementation above, we have used nearly all the important properties of the ExceptionContext. First, the check is used for the ExceptionHandled that returns a Boolean value if the exception has been handled or not. If not then Check for the type of exception that has arisen.

Since here we have used the NullReferenceException, we check for that exception. Then if the conditions are satisfied/passed we manipulate the result and return the RedirectResult (ActionResult type) and let the users land on a custom error page created in the application, to avoid the yellow dreaded screen. The use of the filter is pretty simple since this custom filter extends from the FilterAttribute. So based on the usage, this can be used as [CustomExceptionFilter] on the Controller Level or the individual Action level, whichever is relevant.

// Overcontroller
[CustomExceptionFilter]
public class HomeController : Controller
{
    // ......
}
// OvertheAction
[CustomExceptionFilter]
public ActionResult Index()
{
    // .......
}

Now, let's explain the built-in HandleAttribute. This is a built-in class used in a similar way as a filter attribute in MVC applications. The most important thing is this attribute works only when the custom errors in the web.config are enabled or set to true.

The default mode for this element is RemoteOnly which will only work out when the application is deployed and the request is made from some other systems. Let's look at the properties of the HandleError Attribute.

• ExceptionType: This property, as the name suggests, indicates the attribute of the type of exception it needs to handle.
• View: This is the property that we need to specify to let the attribute land the end users after handling the exception.
• Master: If we have a special layout for the error page then this master can be set to that layout path. If left empty, this will take the default layout of the application for the error pages.

Thus, the following code snippet shows how to use the HandleError attribute.

[HandleError(ExceptionType = typeof(NullReferenceException), View = "CustomErrorPage")]
public class SomeController
{
    public ActionResult SomeAction()
    {
        // ........
        var testVal = null;
        // Unhandled and used..
    }
}

Caution

While reading through Adam Freeman, a very interesting note of caution was said when using the HandleError attribute. In the custom error page, we would be using the HandleError Info like the Stack Trace, the exception message and so on. Since we would not like to show this to the end user, we need to put the stack trace inside a hidden field or make the HTML tag invisible because The view is not displayed to the user unless the Exception.StackTrace is included in the View.

Conclusion

Thus, we learned the creation of custom exception filters as well as the built-in filters in MVC applications. There are various ways/tools now to handle exceptions, but still, we can make use of these filters to avoid detrimental effects on our applications.

References

Adam Freeman-Professional ASP.Net MVC 4 and MSDN

I hope this will help developers and beginners. The concept is interesting when we use them. So start using and enjoy coding.