无需写try/catch，也能正常处理异常

对于企业应用的开发者来说，异常处理是一件既简单又复杂的事情。说其简单，是因为相关的编程无外乎try/catch/finally+throw而已；说其复杂，是因为我们往往很难按照我们真正需要的策略来处理异常。我一直有这样的想法，理想的企业应用开发中应该尽量让框架来完成对异常的处理，最终的开发人员在大部分的情况下无需编写异常处理相关的任何代码。在这篇文章中我们将提供一个解决方案来让ASP.NET应用利用EntLib的异常处理模块来实现自动化的异常处理。

源代码：
Sample1[通过重写Page的OnLoad和OnRaisePostBackEvent方法]
Sample2[通过自动封装注册的EventHandler]

一、EntLib的异常处理方式
二、实例演示
三、通过重写Page的OnLoad和RaisePostBackEvent方法实现自动异常处理
四、IPostBackDataHandler
五、EventHandlerWraper
六、对控件注册事件的自动封装
七、AlertHandler

一、EntLib的异常处理方式

所谓异常，其本意就是超出预期的错误。既然如此，异常处理的策略就不可能一成不变，我们不可能在开发阶段就制定一个完备的异常处理策略来处理未来发生的所有异常。异常处理策略应该是可配置的，能够随时进行动态改变的。就此而言，微软的企业库（以下简称EntLib）的异常处理应用块（Exception Handling Application Block）是一个不错的异常处理框架，它运行我们通过配置文件来定义针对具体异常类型的处理策略。

针对EntLib的异常处理应用块采用非常简单的编程方式，我们只需要按照如下的方式捕捉抛出的异常，并通过调用ExceptionPolicy的HandleException根据指定的异常策略进行处理即可。对于ASP.NET应用来说，我们可以注册HttpApplication的Error事件的形式来进行统一的异常处理。但是在很多情况下，我们往往需要将异常控制在当前页面之内（比如当前页面被正常呈现，并通过执行一段JavaScript探出一个对话框显示错误消息），我们往往需要将下面这段相同的代码结构置于所有控件的注册事件之中。

try
{
    //业务代码
}
catch(Exception ex)
{
    if(ExceptionPolicy.HandleException(ex,"exceptionPolcyName"))
    {
        throw;
    }
}

我个人不太能够容忍完全相同的代码到处出现，代码应该尽可能地重用，而不是重复。接下来我们就来讨论如何采用一些编程上的手段或者技巧来让开发人员无须编写任何的异常处理代码，而抛出的确却能按照我们预先指定的策略被处理。

二、实例演示

为了让读者对“自动化异常处理”有一个直观的认识，我们来做一个简单的实例演示。我们的异常处理策略很简单：如果后台代码抛出异常，异常的相关信息按照预定义的格式通过Alert的方式显示在当前页面中。如下所示的是异常处理策略在配置文件中的定义，该配置中定义了唯一个名为“default”的异常策略，该策略利用自定义的AlertHandler来显示异常信息。配置属性messageTemplate定义了一个模板用于控制显示消息的格式。

<configuration>
  ...
  <exceptionHandling>
    <exceptionPolicies>
      <add name="default">
        <exceptionTypes>
          <add type="System.Exception, mscorlib"
                  postHandlingAction="None" name="Exception">
            <exceptionHandlers>
              <add name="Alert Handler" type="AutomaticExceptionHandling.AlertHandler, AutomaticExceptionHandling"
                   messageTemplate="[{ExceptionType}]{Message}"/>
            </exceptionHandlers>
          </add>
        </exceptionTypes>
      </add>
    </exceptionPolicies>
  </exceptionHandling>
</configuration>

现在我们定义一个简单的页面来模式自动化异常处理，这个页面是一个用于进行除法预算的计算器。如下所示的该页面的后台代码，可以看出它没有直接继承自Page，而是继承自我们自定义的基类PageBase，所有异常处理的机制就实现在此。Page_Load方法收集以QueryString方式提供的操作数，并转化成整数进行除法预算，最后将运算结果显示在表示结果的文本框中。计算按钮的Click事件处理方法根据用户输入的操作数进行除法运算。两个方法中均没有一句与异常处理相关的代码。

public partial class Default : PageBase
{
    protected void Page_Load(object sender, EventArgs e)
    {
        if (!this.IsPostBack)
        {
            string op1 = Request.QueryString["op1"];
            string op2 = Request.QueryString["op2"];
            if (!string.IsNullOrEmpty(op1) && !string.IsNullOrEmpty(op2))
            {
                this.txtResult.Text = (int.Parse(op1) / int.Parse(op2)).ToString();
            }
        }
    }

    protected void btnCal_Click(object sender, EventArgs e)
    {
        int op1 = int.Parse(this.txtOp1.Text);
        int op2 = int.Parse(this.txtOp2.Text);
        this.txtResult.Text = (op1 / op2).ToString();
    }
}

现在运行我们程序，可以想象如果在表示操作数的文本框中输入一个非整数字符，调用Int32的Parse方法时将会抛出一个FormatException异常，或者将被除数设置为0，则会抛出一个DivideByZeroException异常。如下面的代码片断所示，在这两种情况下相应的错误信息按照我们预定义的格式以Alert的形式显示出来。

三、通过重写Page的OnLoad和RaisePostBackEvent方法实现自动异常处理

我们知道ASP.NET应用中某个页面的后台代码基本上都是注册到页面及其控件的事件处理方法，除了第一次呈现页面的Load事件，其他事件均是通过PostBack的方式出发的。所以我最初的解决方案很直接：就是提供一个PageBase，在重写的OnLoad和RaisePostBackEvent方法中进行异常处理。PageBase的整个定义如下所示：

public abstract class PageBase: Page
{
    public virtual string ExceptionPolicyName { get; set; }
    public PageBase()
    {
        this.ExceptionPolicyName = "default";
    }

    protected virtual string GetExceptionPolicyName()
    {
        ExceptionPolicyAttribute attribute = this.GetType().GetCustomAttributes(true)
            .OfType<ExceptionPolicyAttribute>().FirstOrDefault();
        if (null != attribute)
        {
            return attribute.ExceptionPolicyName;
        }
        else
        {
            return this.ExceptionPolicyName;
        }
    }

    protected override void OnLoad(EventArgs e)
    {
        this.InvokeAndHandleException(() => base.OnLoad(e));
    }

    protected override void RaisePostBackEvent(IPostBackEventHandler sourceControl, string eventArgument)
    {
        this.InvokeAndHandleException(()=>base.RaisePostBackEvent(sourceControl, eventArgument));
    }

    private void InvokeAndHandleException(Action action)
    {
        try
        {
            action();
        }
        catch (Exception ex)
        {
            string exceptionPolicyName = this.GetExceptionPolicyName();
            if (ExceptionPolicy.HandleException(ex, exceptionPolicyName))
            {
                throw;
            }
        }
    }
}

如上面的代码片断所示，在重写的OnLoad和RaisePostBackEvent方法中，我们采用与EntLib异常处理应用块的编程方式调用基类的同名方法。我们通过属性ExceptionPolicyName 指定了一个默认的异常处理策略名称（“default”，也正是配置文件中定义个策略名称）。如果某个页面需要采用其他的异常处理策略，可以在类型上面应用ExceptionPolicyAttribute特性来制定，该特性定义如下：

[AttributeUsage( AttributeTargets.Class, AllowMultiple = false)]
public class ExceptionPolicyAttribute: Attribute
{
    public string ExceptionPolicyName { get; private set; }
    public ExceptionPolicyAttribute(string exceptionPolicyName)
    {
        Guard.ArgumentNotNullOrEmpty(exceptionPolicyName, "exceptionPolicyName");
        this.ExceptionPolicyName = exceptionPolicyName;
    }
}

四、IPostBackDataHandler

通过为具体Page定义基类并重写OnLoad和RaisePostBackEvent方法的方式貌似能够实现我们“自动化异常处理”的目标，而且针对我们提供的这个实例来说也是OK的。但是这却不是正确的解决方案，原因在于并非所有控件的事件都是在RaisePostBackEvent方法执行过程中触发的。ASP.NET提供了一组实现了IPostBackDataHandler接口的控件类型，它们会向PostBack的时候向服务端传递相应的数据，我们熟悉的ListControl（DropDownList、ListBox、RadioButtonList和CheckBoxList等）就属于此类。

public interface IPostBackDataHandler
{
    bool LoadPostData(string postDataKey, NameValueCollection postCollection);
    void RaisePostDataChangedEvent();
}

当Page的ProcessRequest（这是对IHttpHandler方法的实现）被执行的的时候，会先于RaisePostBackEvent之前调用另一个方法RaiseChangedEvents。在RaiseChangedEvents方法执行过程中，如果目标类型实现了IPostBackDataHandler接口，会调用它们的RaisePostDataChangedEvent方法。很多表示输入数据改变的事件（比如ListControl的SelectedIndexChanged事件）就是被RaisePostDataChangedEvent方法触发的。如果可能，我们可以通过重写RaiseChangedEvents方法的方式来解决这个问题，不过很可惜，这个方法是一个内部方法。

五、EventHandlerWraper

要实现“自动化异常处理”的根本手段就是将页面和控件注册的事件处理方法置于一个try/catch块中执行，并采用EntLib的异常处理应用块的方式对抛出的异常进行处理。如果我们能够改变页面和控件注册的事件，使注册的事件处理器本身就具有异常处理的能力，我们“自动化异常处理”的目标也能够实现。为此我定义了如下一个用于封装EventHandler的EventHandlerWrapper，它将EventHandler的置于一个try/catch块中执行。对于EventHandlerWrapper的设计思想，在我两年前写的《如何编写没有Try/Catch的程序》一文中具有详细介绍。

public class EventHandlerWrapper
{
    public object Target { get; private set; }
    public MethodInfo Method { get; private set; }
    public EventHandler Hander { get; private set; }
    public string ExceptionPolicyName { get; private set; }

    public EventHandlerWrapper(EventHandler eventHandler, string exceptionPolicyName)
    {
        Guard.ArgumentNotNull(eventHandler, "eventHandler");
        Guard.ArgumentNotNullOrEmpty(exceptionPolicyName, "exceptionPolicyName");

        this.Target = eventHandler.Target;
        this.Method = eventHandler.Method;
        this.ExceptionPolicyName = exceptionPolicyName;
        this.Hander += Invoke;
    }
    public static implicit operator EventHandler(EventHandlerWrapper eventHandlerWrapper)
    {
        Guard.ArgumentNotNull(eventHandlerWrapper, "eventHandlerWrapper");
        return eventHandlerWrapper.Hander;
    }
    private void Invoke(object sender, EventArgs args)
    {
        try
        {
            this.Method.Invoke(this.Target, new object[] { sender, args });
        }
        catch (TargetInvocationException ex)
        {
            if (ExceptionPolicy.HandleException(ex.InnerException, this.ExceptionPolicyName))
            {
                throw;
            }
        }
    }
}

由于我们为EventHandlerWrapper定义了一个针对EventHandler的隐式转化符，一个EventHandlerWrapper对象能够自动被转化成EventHandler对象。我们现在的目标就是：将包括页面在内的所有控件注册的EventHandler替换成用于封装它们的EventHandlerWrapper。我们知道所有控件的基类Control具有如下一个受保护的只读属性Events，所有注册的EventHandler就包含在这里，而我们的目标就是要改变所有控件该属性中保存的EventHandler。

public class Control
{
    protected EventHandlerList Events{get;}
}

其实要改变Events属性中的EventHandler也并不是一件容易的事，因为其类型EventHandlerList 并不如它的名称表现出来的那样是一个可枚举的列表，而是一个通过私有类型ListEntry维护的链表。要改变这些注册的事件，我们不得不采用反射，而这会影响性能。不过对应并非访问量不高的企业应用来说，我觉得这点性能损失是可以接受的。整个操作被定义在如下所示的EventHandlerWrapperUtil的Wrap方法中。

private static class EventHandlerWrapperUtil
{
    private static Type listEntryType;
    private static FieldInfo handler;
    private static FieldInfo key;
    private static FieldInfo next;

    static EventHandlerWrapperUtil()
    {
        listEntryType = Type.GetType("System.ComponentModel.EventHandlerList+ListEntry, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089");
        BindingFlags bindingFlags = BindingFlags.Instance | BindingFlags.NonPublic;
        handler = listEntryType.GetField("handler", bindingFlags);
        key     = listEntryType.GetField("key", bindingFlags);
        next    = listEntryType.GetField("next", bindingFlags);
    }

    public static void Wrap(object listEntry, string exceptionPolicyName)
    {
        EventHandler eventHandler = handler.GetValue(listEntry) as EventHandler;
        if (null != eventHandler)
        {
            EventHandlerWrapper eventHandlerWrapper = new EventHandlerWrapper(eventHandler, exceptionPolicyName);
            handler.SetValue(listEntry, (EventHandler)eventHandlerWrapper);
        }
            object nextEntry = next.GetValue(listEntry);
        if(null != nextEntry)
        {
            Wrap(nextEntry,exceptionPolicyName);
        }
    }
}

六、对控件注册事件的自动封装

对包括页面在内的所有控件注册时间的自动封装同样实现在作为具体页面积累的PageBase中。具体的实现定义在WrapEventHandlers方法中，由于Control的Events属性是受保护的，所以我们还得采用反射。该方法最终的重写的OnInit方法中执行。此外，由于EventHandlerWraper仅仅能够封装EventHandler，但是很多控件的事件却并非EventHandler类型，所以这是一个挺难解决的问题。

public abstract class PageBase : Page
{
    private static PropertyInfo eventsProperty;
    private static FieldInfo headField;

    public static string ExceptionPolicyName { get; set; }
    static PageBase()
    {
        ExceptionPolicyName = "default";
        eventsProperty = typeof(Control).GetProperty("Events", BindingFlags.Instance | BindingFlags.NonPublic);
        headField = typeof(EventHandlerList).GetField("head", BindingFlags.Instance | BindingFlags.NonPublic);
    }

    protected override void OnInit(EventArgs e)
    {
        base.OnInit(e);
        Trace.Write("Begin to wrap events!");
        this.WrapEventHandlers(this);
        Trace.Write("Wrapping events ends!");
    }

    protected virtual void WrapEventHandlers(Control control)
    {
        string exceptionPolicyName = this.GetExceptionPolicyName();
        EventHandlerList events = eventsProperty.GetValue(control, null) as EventHandlerList;
        if (null != events)
        {
            object head = headField.GetValue(events);
            if (null != head)
            {
                EventHandlerWrapperUtil.Wrap(head, exceptionPolicyName);
            }
        }
        foreach (Control subControl in control.Controls)
        {
            WrapEventHandlers(subControl);
        }
    }

    protected virtual string GetExceptionPolicyName()
    {
        ExceptionPolicyAttribute attribute = this.GetType().GetCustomAttributes(true)
            .OfType<ExceptionPolicyAttribute>().FirstOrDefault();
        if (null != attribute)
        {
            return attribute.ExceptionPolicyName;
        }
        else
        {
            return ExceptionPolicyName;
        }
    }
}

七、AlertHandler

我想有人对用于显示错误消息对话框的AltertHandler的实现很感兴趣，下面给出了它和对应的AlertHandlerData的定义。从如下的代码可以看出，AltertHandler仅仅是调用Page的RaisePostBackEvent方法注册了一段显示错误消息的JavaScript脚本而已。

[ConfigurationElementType(typeof(AlertHandlerData))]
public class AlertHandler: IExceptionHandler
{
    public string MessageTemplate { get; private set; }
    public AlertHandler(string messageTemplate)
    {
        this.MessageTemplate = messageTemplate;
    }

    protected string FormatMessage(Exception exception)
    {
        Guard.ArgumentNotNull(exception, "exception");
        string messageTemplate = string.IsNullOrEmpty(this.MessageTemplate) ? exception.Message : this.MessageTemplate;
        return messageTemplate.Replace("{ExceptionType}", exception.GetType().Name)
                                .Replace("{HelpLink}", exception.HelpLink)
                                .Replace("{Message}", exception.Message)
                                .Replace("{Source}", exception.Source)
                                .Replace("{StackTrace}", exception.StackTrace);
    }

    public Exception HandleException(Exception exception, Guid handlingInstanceId)
    {
        Page page = HttpContext.Current.Handler as Page;
        if (null != page)
        {

            string message = this.FormatMessage(exception);
            string hiddenControl = "hiddenCurrentPageException";
            page.ClientScript.RegisterHiddenField(hiddenControl, message);
            string script = string.Format("<Script language=\"javascript\">var obj=document.forms[0].{0};alert(unescape(obj.value));</Script>",
                new object[] { hiddenControl });
            page.ClientScript.RegisterStartupScript(base.GetType(), "ExceptionHandling.AlertHandler", script);
        }
        return exception;
    }
}

public class AlertHandlerData : ExceptionHandlerData
{
    [ConfigurationProperty("messageTemplate", IsRequired = false, DefaultValue="")]
    public string MessageTemplate
    {
        get { return (string)this["messageTemplate"]; }
        set { this["messageTemplate"] = value; }
    }

    public override IEnumerable<TypeRegistration> GetRegistrations(string namePrefix)
    {
        yield return new TypeRegistration<IExceptionHandler>(() => new AlertHandler(this.MessageTemplate))
        {
            Name = this.BuildName(namePrefix),
            Lifetime = TypeRegistrationLifetime.Transient
        };
    }
}