ILearnable .Net

March 30, 2008

General exception handling in web parts

Filed under: Uncategorized — andreakn @ 23:33
Tags:

Some time ago, I wrote a general transparent exception handling module for use in a MOSS 2007 (Sharepoint) solution. The solution had many web parts, web parts that would often break, causing the entire page they were on to crash. This was causing our testers no end of misery, as they couldn’t easily see which part of the page was responsible for the crash, nor could they continue their testing until the web part had been fixed. Often, the crashing web part wasn’t even relevant for the testers, but it still kept them from doing their work. Clearly something needed to be done.

You might argue that the best solution would be to buckle up and just fix the dang web parts.. but there were a lot of them, and the coders responsible for the mess had moved on (sounds familiar?) so we had the idea to use a general all-purpose exception handling strategy for the parts.

We wanted a crash in a web part or web control etc. not to crash the entire page, but instead to output the stacktrace inline in the web page during development, and to have a friendly message (defined by the webparts themselves, or a standard message) outputted to the user in run time, in stead of bringing the entire page down.

At the time we didn’t know of any such solution. (I still don’t).
The best, I think, would be if something like what I made (the file is included) was included into the ASP.Net framework. (if any of you ASP.Net guys are reading this: feel free to take my code and adapt it. It works better the higher it is in the class hierarchy
It could for instance be a part of System.Web.UI.WebControls.WebControl, with some web.config setting you could tweak to activate it… it would help heaps during development.. at least it would help me :) )

so, on to the solution we ended with:
I made a BaseWebPart which all the other web parts (the ones that were crashing intermittently) would inherit from. When inherited from, the BaseWebPart would ensure that a try/catch surrounded all the calls coming from the ASP.Net framework (Render, CreateChildControls .. etc.) so that a crash happening in one of these was handled nicely.
Each web part could then override a method called HandleException to control what happened if it crashed. the default behaviour (if they didn’t override) was set to be

render the stacktrace when in debug mode
or
render a standard error message when in release mode

In order to wrap each framework call with exception handling,
we had a two-tiered approach in which
1) the first tier (ExceptionHandlingWebPartBase) overrides and seals methods,
2) then applies try/catch to a new set of methods, forwarding method parameters
3) these new methods are overridden in the second tier (BaseWebPart)
4) where they are sealed and a call is made to new virtual methods that are named the same as the framework methods.
5) These methods (now with a catch-block around them) are then overridden as needed in a regular web part that inherits from BaseWebPart. The exception handling is thus transparent to the inheritor.

The only downside of this module was that MOSS has several “base” web parts you would inherit from to make your own web parts, so this BaseWebPart had to be duplicated once for each of these. 
We also wanted this functionality on web controls, 
so we had to basically duplicate the code to make a BaseWebControl also.
If this error handling module was included higher in the hierarchy, for instance in WebControl or Control, once would be enough to cover all the different cases. Unfortunately c# doesn’t allow mixins, or we would probably be able to get away with applying the exception handling all over in one fell swoop. As it stands, 4-5 classes of duplicated, identical code was found to be preferrable to 40-50 classes with duplicated exception handling logic.

“did it work?” you ask? well the benefits derived from this setup included
1) no need to emergency hotfix testing environments during testing
2) guaranteed logging of exceptions in production
3) a generally more sober error classification from the testers (before they would just say “everyting is down, this page doesn’t work – this is unacceptable, level 1 error”
4) some exceptions in the web parts snuck into production, but instead of causing the entire page to halt, a friendly message was shown, buying us a great deal of time in fixing the problem ( next release instead of hotfix)

I’m definately using this setup again the next time I’m in a project with lots of web parts, web controls or custom controls.

Here is the code:

using System;
using System.IO;
using System.Text;
using System.Web.UI;
using System.Web.UI.WebControls.WebParts;

///*'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
/// This is the work of Andreas Knudsen (andreas.knudsen [ at ] gmail.com)
/// Anyone may use this work freely as it stands, or change it to suit their needs
/// on one condition: All use is on your own risk. It works for me, but I will not be
/// liable for any losses incurred by the use of this work. 
/// 
/// If you would hold me responsible, you are not to use this work.
/// ************************************************************************************
/// 
/// In order to be truly useful, customizations are needed on lines 120 and 130
/// 
/// ************************************************************************************
namespace Util
{
/// <summary> 
/// Base class for web part development. 
/// All web parts should inherit from this class. 
/// Exceptions thrown from web parts inheriting from this base 
/// will not crash the Page the web part is on, but rather do one of two things:
/// 
/// 1)If compiled in debug mode: Render the stacktrace of the exception inline in the web page
/// 2)If compiled in release mode: Render a friendly error message inline in the web page.
/// 
/// This behaviour can be overridden by inheritors by overriding the method HandleException
///  
/// HOW THIS WORKS:
/// -------
/// In order to wrap each framework call with exception handling, 
/// we have a two-tiered approach in which 
/// 1) the first tier (ExceptionHandlingWebPartBase) overrides and seals methods, 
/// 2) then applies try/catch to a new set of methods, forwarding method parameters
/// 3) these new methods are overridden in the second tier (BaseWebPart)
/// 4) where they are sealed and a call is made to new virtual methods that are named the 
/// same as the framework methods.
/// 5) These methods (now with a catch-block around them) are then overridden as needed in a 
/// regular web part that inherits from BaseWebPart. The exception handling is thus 
/// transparent to the inheritor.
/// </summary>
public abstract class BaseWebPart : ExceptionHandlingWebPartBase
{
  #region temp methods for method piping (overrides and seals methods from ExceptionHandlingWebPartBase)
  /*
         * These methods re part of the plumbing necessary to give inheritors
         * the expected interface.
         */
  public override sealed void RenderWebPart(HtmlTextWriter writer)
  {
      Render(writer);
  }

  public override sealed void CreateWebPartChildControls()
  {
      CreateChildControls();
  }

  public override sealed void InitWebPart(EventArgs e)
  {
      OnInit(e);
  }

  public sealed override void PreRenderWebPart(EventArgs e)
  {
      OnPreRender(e);
  }

  public sealed override void LoadWebPart(EventArgs e)
  {
      OnLoad(e);
  }
  #endregion
  #region Methods in which exceptions are now handled.
  protected new virtual void Render(HtmlTextWriter writer)
  {
      base.RenderWebPart(writer);
  }
  protected new virtual void CreateChildControls()
  {
      base.CreateWebPartChildControls();
  }

  protected new virtual void OnInit(EventArgs e)
  {
      base.InitWebPart(e);
  }

  protected new virtual void OnLoad(EventArgs e)
  {
      base.LoadWebPart(e);
  }

  protected new virtual void OnPreRender(EventArgs e)
  {
      base.PreRenderWebPart(e);
  }
  #endregion
}


public abstract class ExceptionHandlingWebPartBase : WebPart
{

  #region Exception handling section
  private StringBuilder _errorOutput;
  private bool _abortProcessing;
  public virtual bool AbortProcessing
  {
      get { return _abortProcessing; }
      set { _abortProcessing = value; }
  }

  public virtual void HandleException(Exception e, HtmlTextWriter writer)
  {
#if !DEBUG
      writer.Write("TODO: Insert helpful error message here");
#else
      writer.Write(e.Message + "<br/>" + e.StackTrace);
#endif

  }

  public void ExceptionHappened(Exception ex)
  {
      AbortProcessing = true;
      //TODO: use own logging framework here:
      //Logger.Log(Severity.Error, ex.Message + " " + ex.StackTrace);

      HandleException(ex, new HtmlTextWriter(new StringWriter(_errorOutput)));
  }

  #endregion

  #region Override framework methods for method piping
  protected override sealed void CreateChildControls()
  {

      if (!AbortProcessing)
      {
          try
          {
              CreateWebPartChildControls();
          }
          catch (Exception e)
          {
              ExceptionHappened(e);
          }
      }
  }

  protected override sealed void OnInit(EventArgs e)
  {
      AbortProcessing = false;

      _errorOutput = new StringBuilder();

      try
      {
          InitWebPart(e);
      }
      catch (Exception ex)
      {
          ExceptionHappened(ex);
      }
  }
  protected override sealed void Render(HtmlTextWriter writer)
  {
      StringBuilder tempOutput = new StringBuilder();
      if (!AbortProcessing)
      {
          HtmlTextWriter tempWriter = new HtmlTextWriter(new StringWriter(tempOutput));

          try
          {
              RenderWebPart(tempWriter);
          }
          catch (Exception ex)
          {
              ExceptionHappened(ex);
          }
      }
      if (AbortProcessing)
      {
          writer.Write(_errorOutput.ToString());
      }
      else
      {
          writer.Write(tempOutput.ToString());
      }
  }
  protected override sealed void OnLoad(EventArgs e)
  {
      if (!AbortProcessing)
      {
          try
          {
              LoadWebPart(e);
          }
          catch (Exception ex)
          {
              ExceptionHappened(ex);
          }


      }
  }
  protected override sealed void OnPreRender(EventArgs e)
  {
      if (!AbortProcessing)
      {
   
          try
          {
              PreRenderWebPart(e);
          }
          catch (Exception ex)
          {
              ExceptionHappened(ex);
          }

      }
  }
  #endregion

  #region Temp methods for method piping (will be overridden and sealed in subclass)
  public virtual void RenderWebPart(HtmlTextWriter writer)
  {
      EnsureChildControls();
      base.Render(writer);
  }
  public virtual void CreateWebPartChildControls()
  {
      base.CreateChildControls();
  }
  public virtual void InitWebPart(EventArgs e)
  {
      base.OnInit(e);
  }
  public virtual void LoadWebPart(EventArgs e)
  {
      base.OnLoad(e);
  }
  public virtual void PreRenderWebPart(EventArgs e)
  {
      base.OnPreRender(e);
  }
  #endregion
}
}
About these ads

5 Comments »

  1. Thanks, Andreas.
    Great work. Must definitely try this out next time I’m creating a web part.

    Comment by Frank-Ove Kristiansen — April 15, 2008 @ 03:42 | Reply

  2. Responded to this post on blogspot.com, then discovered you moved here.

    Great post, trying to make it work in VB.NET. Having a problem with the “sealed” and “override” C# parameters. For example, if Render is override sealed (NotOverridable Overrides in VB) in the ExceptionHandlingWebPartBase class, I get an error when I try to use Render in the BaseWebPart, Visual Studio 2008 tells me that Render should be declared “overrides” there. Can you help with the VB.NET equivalent of what you are doing? Thanks!

    Comment by Chris — January 13, 2010 @ 15:36 | Reply

    • I’m not quite sure as I haven’t worked with VB.Net but I think that if you use public Overridable Shadows Render... in BaseWebPart you should be good to go. The main point here is that you define the method as a new method, which has nothing to do with the one that shares its signature in the base class (new in C#, Shadows in VB.Net) and that base classes may override the method if they wish (virtual in C#, Overridable in VB.Net). The last point is important because web developers may be expecting to be able to override Render to do hacking there, (though I don’t especially encourage anyone to actually do so)

      Comment by andreakn — January 13, 2010 @ 16:13 | Reply

  3. Many thanks Andreas, Nice Idea!
    I think we can tweak this a bit and use it for dynamic user controls in ASP.Net…. Did you by any chance had the time to implement it?
    ~Abhinav

    Comment by Abhinav Dhar — May 26, 2010 @ 06:02 | Reply

    • I’m not quite sure what you’re asking, so I’ll answer as best I can:

      Did I implement this with static controls (controls used in markup): yes
      Did I implement this in VB.Net?: no
      Did I implement this with dynamic controls (controls injected into page programatically): yes-ish.
      – we use web services to render content using this technique:

      public string RenderControl(string pathcontrol)
      {
          string html;
      
          var page = new Page();
          var control = page.LoadControl(path);            
          page.Controls.Add(control);
      
          // do stuff to the control (give it some data to work on)
      
          using (var writer = new StringWriter())
          {
              HttpContext.Current.Server.Execute(page, writer, false);
              html = writer.ToString();
          }
      
          return html;
      }
      

      And it works great

      (we don’t have to worry about postbacks though, but I can’t see why it should be a problem)

      Comment by andreakn — May 26, 2010 @ 06:19 | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Rubric Theme. Create a free website or blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: