Geeks With Blogs


Locations of visitors to this page

View ► Sanjay Uttam []'s profile on LinkedIn

Add to Google Reader or Homepage

Sanjay Uttam Predominantly .NET

In the first post in this series, I provided a little info on the HandleError attribute in MVC 1.  In case you don’t want to flip back, the HandleError attribute can decorate a method or a class and will push your users to a generic errors view provided customErrors is “On” or “RemoteOnly”.  There’s a little more to it, but that’s all the background we need for this post.

The out-of-the-box HandleError attribute works well, until you’re in a scenario where you need to do more than hide your errors.  Typically, you may want to do some logging or fire-off some alerts.  Now, as luck should have it, I did some searching before writing this up and Danny Tuppeny already has a great post on this very subject…I encourage you to take a peak at his post, as I’ve provided a very high-level, yet functional summary below.

The facts are these…

- System.Web.Mvc.Controller contains an OnException method that gets fired when an exception occurs [provided custom errors are On/RemoteOnly in the web.config]

- The OnException method can easily be overridden, allowing you to either completely change behavior or add behavior (by calling base.OnException)

- This method will fire regardless of whether your class or method is decorated with HandleError

This means that your could will look like this:

   1: using System;
   2: using System.Collections.Generic;
   3: using System.Linq;
   4: using System.Web;
   5: using System.Web.Mvc;
   7: namespace MvcErrorHandling.Controllers
   8: {
   9:     public class ControllerBase : System.Web.Mvc.Controller
  10:     {
  11:         protected override void OnException(ExceptionContext filterContext)
  12:         {
  13:             //Do whatever stuff you'd like
  14:             DoSomeOtherStuff();
  16:             //Displays a friendly error, doesn't require HandleError
  17:             filterContext.ExceptionHandled = true;
  18:             this.View("Error").ExecuteResult(this.ControllerContext);
  20:             //Displays a friendly error, *requires* HandlError
  21:             //base.OnException(filterContext);
  22:         }
  24:         protected void DoSomeOtherStuff() { /* brevity */ }
  25:     }
  26: }

To get the above code to work you’d simply make your controller inherit from ControllerBase.  Of course, you’d likely have additional utility-methods in this class that you’d need in multiple controllers. 

Lines 17 and 18 can be used to push the user to your error view after you execute the DoSomeOtherStuff() method – this would not require the HandleError attribute.  Alternatively, you can execute System.Web.Mvc.Controller’s OnException by calling it explicitly as it’s done on line 21.  In this case, the HandleError would be required to push your use down the custom-error path you’ve got configured. 

And that’s pretty much all there is to centralizing & customizing your error-handling in MVC 1.  

kick it on

Share this post :

Technorati Tags: ,
Posted on Monday, November 9, 2009 6:38 PM | Back to top

Copyright © Sanjay Uttam | Powered by: