Exception handling is one of the major areas of an application development and when it is a web application, it requires additional care so that errors gets handled gracefully without breaking the complete system and relevant information is shown to the users with proper error message. Also making sure that no internal details gets propagated till user when application crashes or error occur because it could be a major security threat. All the exception details and other additional information should be logged so that it can be later used for proper investigation. In this post we will talk about the few options available to handle the exception in ASP.NET MVC and best practices to use them.
In ASP.NET MVC, the request first hits the route handler which identifies the controller and action to be serving the request. We put the whole logic in our controller itself. There are various type of filters in ASP.NET MVC that are also part of the request processing and some time we extend them to put some custom logic based on specific requirement. There is an Exception filter for handling exceptions as well and this Filter is key in handling exceptions in MVC. First let’s see available filters and their order of execution in request processing flow
So we can see here that there are four filters in total and exception filter executes at end. It means if we use exception filter then it will be caught there whether the exception occurs in Action or even in Authorization/Action/Result filters.
Note – Filters are added as an attribute so it also inherits from ‘System.Attribute’.
Broadly we can say that exceptions may occur in controller or in some cases while processing the routes and filters. But as most of our core logic resides in action so the chances in are most. Before focusing on filters, let’s first discuss one basic way to handle to exception that is part of C#.
Using Try/Catch block
This is C# feature and one of the basic ways to handle exceptions so we can wrap all our code in our Action as below.
try
{
// Add your code here
}
catch
{
// Exception Handling code
}
But there are many issues with this approach and the primary issue is the limitation to single Action. To handle that, we need to put try catch block in each Action of the application which is repeating the same exception handling code which defies the code re-usability logic. It does not mean that we should never use it but there are some scenarios where we require to perform some another activity in case of exception without letting the user know or more specifically if you are calling to some third part services etc. then it might be a good Idea to use this approach.
Global Error Handling
Global error handling is one of the simplest way to handle exceptions at application level. It leverages the Exception Filter to handle exception and applies at application level itself. This is out of the box feature and can be easily set up by following step.
- Set customErrors errors as On in web.config as
<customErrors mode="On"></customErrors>
- Have a common error view (in Shared folder with name error.cshtml) which will be shown in case of error as
Here we see that we get a model of type HandleErrorInfo class which provides the details about that error occurred, controller and action name etc. - Make sure we registere HandleErrorAttribute in Application_Start (Global.asax)method
RegisterGlobalFilters(GlobalFilters.Filters); public static void RegisterGlobalFilters(GlobalFilterCollection filters) { filters.Add(new HandleErrorAttribute()); }Now if any error occurs then error view will be shown.
Customizing global error handling
We have seen that how easily we can configure the error handling at application level. But what if we want to handle it bit differently. Say we want to save the details in database and/or want to send the email notification when error occurs. We have two options here
-
Override OnException method :
We can override OnException method as in our controller as
protected override void OnException(ExceptionContext filterContext) { Exception ex = filterContext.Exception; // Log Exception ex in database // Notify admin team filterContext.ExceptionHandled = true; // Setting the View in case of error filterContext.Result = new ViewResult() { ViewName = "CustomErrorView" }; }Here we can log our exception, send the mail etc. and set our own view that will be shown (like here I used CustomErrorView) in case of error. But this code won’t be reusable and need to write in each controller wherever we need.
- To handle it in better way, we need to extend HandleErrorAttribute as
public class MyCustomHandleErrorAttribute : HandleErrorAttribute { public override void OnException(ExceptionContext filterContext) { Exception ex = filterContext.Exception; // Log Exception ex in database // Notify admin team filterContext.ExceptionHandled = true; filterContext.ExceptionHandled = true; filterContext.Result = new ViewResult() { ViewName = "DVZ" }; } }And instead of registering the default HandleErrorAttribute we need to register the custom one as
filters.Add(new MyCustomHandleErrorAttribute());
Now this custom error attribute will be used in the whole application.
Handling exception at more Granular level
Till now, we have seen that how can we apply filter at global level. MVC allows us to handle exceptions at more granular level similar at controller and action level as
For Controller either we can use the default HandleErrorAttribute or we can use the extended attribute similar to MyCustomHandleErrorAttribute and put it at controller as
[MyCustomHandleError]
public class EventController : Controller
{
// Controller code
…
}
For Action
public class EventController : Controller
{
[MyCustomHandleError]
public ActionResult About()
{
// Action code
}
…
}
Note – Here I have put ‘MyCustomHandleError’ as an attribute. We can use default ‘HandleError’ attribute instead of custom one.
Another variation
There may be some scenarios where we may need to show specific view or details based on the type of exception occurs in Controller/Action. In other words, say if in Controller/Action, if a specific exception occurs, then showing user one view and any other exception occurs then show a different view. Let’s see an example
[HandleError(ExceptionType = typeof(DivideByZeroException), View = "DVZ")]
[MyCustomHandleError]
public ActionResult Create()
{
// Action code
}
Here if DivideByZeroException occurs then view DVZ will be loaded else default one would be loaded. We can add as many type of exception based on requirement. Also similarly we can apply at Controller level as well.
ExceptionHandled property usage
In OnException method, you must have seen the following line many times.
filterContext.ExceptionHandled = true;
As the name suggests that when we set it true (default: false), then the exception does not propagate further and it is handled in the same method. Say we have put the Exception Filter at action, added a Global exception filer and we did not set the ExceptionHandled filter or set it false then once the exception is caught by action level exception filter that will be thrown further to next level and caught at global filter. Normally when we handle exception we make it false because we have already handled the exception. But there could be few scenarios where we do something with exception details and throw it further so accordingly we need to set this property.
Exception handling outside the scope of MVC
Exceptions are bound to happen and it can always find the way to reach user. We need to block every route. As we know handled the exceptions using MVC framework features but if something happens outside of the MVC scope. As we know that MVC framework is built on top of the ASP.NET platform then we can use the Application_Error method that is available since beginning to handle Application level error. It can be depicted pictorially as
Here we can see that once the control reaches ASP.NET platform, this method can help us so we should handle the exception here as well and we can put all the logging and notification code here as
protected void Application_Error()
{
Exception ex = Server.GetLastError();
// Log Exception ex in database
// Notify admin team
// Clear the error
Server.ClearError();
// Redirect to a landing page
Response.Redirect("home/index");
}
Note: Application_Error should not be used in replacement MVC global exception filer, because as soon as you get out of MVC scope, you won’t get its execution context which is very important to provide the relevant details about the exception.
Conclusion
We have discussed various possible ways of handling exceptions. We find that all the exception handling moves around the handle error attribute with many variations. Another two that we discussed: using try catch block and using Application_Error. Best solution for any application would be a combination of these approaches like extend HandleErrorAttribute based on the requirement and use it accordingly. Application Error should be used as if an exception somehow find its way to get out from MVC scope, then it will be caught here. Try Catch block should be really avoided as it just not makes the code ugly but we can miss lots of relevant information that may be helpful in fixing the issue so unless specific case, do not use it.
Code Wala 