views:

1047

answers:

5

Not exactly a question this, but something that might help out a few people I hope..

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 steal my code. It would work 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.

and so, on to 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
/// (search for CUSTOMIZE HERE! 
/// 
/// ************************************************************************************
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
  // CUSTOMIZE HERE! 
   writer.Write("TODO: Insert helpful error message here");
#else
   writer.Write(e.Message + "<br/>" + e.StackTrace);
#endif

  }

  public void ExceptionHappened(Exception ex)
  {
   AbortProcessing = true;
   //CUSTOMIZE HERE!
   //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)
   {
    base.OnLoad(e);
    try
    {
     LoadWebPart(e);
    }
    catch (Exception ex)
    {
     ExceptionHappened(ex);
    }


   }
  }
  protected override sealed void OnPreRender(EventArgs e)
  {
   if (!AbortProcessing)
   {
    base.OnPreRender(e);

    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
}
}
+3  A: 

Thanks for sharing, Andreas!

Aidenn
thanks for not downvoting, Just because it's not a question doesn't mean it can't be helpful
AndreasKnudsen
+4  A: 

Very nice, works perfectly. Have combined it with an general httpmodule that catches all other exceptions from sharepoint and those two uses the same utility function for mailing the error information to support and displaying a general error page for the visitor

+1  A: 

Thanks Andreas! I started writing my own, using the same approach. Then I found your solution while looking for a way to display a clean errormessage on screen. As I don't like inventing the wheel twice, I'm using yours now.

Peter
good to be able to help you. Just remember the disclaimer at the top of the code :) (since posting the solution to SO I've used the method in another project with success, so I'm pretty confident it works)
AndreasKnudsen
I have added your error handling with the SmartPart webpart and it works beautifully, so only cheers to you m8! Besides, I would never hold anyone else responsible but myself for problems with code I did not write myself, unless paid for.
Peter
A: 

Thanks your excellent article and for sharing your ideas at EPiServer meetup Andreas!

I’ve been doing almost the same thing with WebParts in EPiServer, but I implemented only one tier until today. Brilliant concept!

Thomas Leela
A: 

I've been playing with this a bit as I'm facing the same issues. It doesn't seem to handle errors which occur during postback events though, e.g. button_click, and I can't seem to work out how that could be done, if at all. Thoughts?

Bjoern

Bjoern
For pages you can override and try/catch PageRaisedPostBackEvent like for the other methods, but for controls you're a bit stuck as ASP.Net bypasses the usercontrol-layer when raising postbacks and go straight to the web control (e.g. button) that fires the event. What you *could* do is to have a base page in your system which all pages inherit from which overrides RaisePostBackEvent(source, eventArgs) and checks whether the source control is really one of your magic controls (or is contained within one (cast to UserControl + parent..)), then do the try/catch there,
AndreasKnudsen