.NET：何时应该 “包装异常”？

背景

提到异常，我们会想到：抛出异常、异常恢复、资源清理、吞掉异常、重新抛出异常、替换异常、包装异常。本文想谈谈 “包装异常”，主要针对这个问题：何时应该 “包装异常”？

“包装异常” 的技术形式

包装异常是替换异常的特殊形式，具体的技术形式如下：

            try
            {
                // do something
            }
            catch (SomeException ex)
            {
                throw new WrapperException("New Message", ex);
            }

注意：WrapperException 需要将 ex 作为 InnerException，这样才不至于丢失 StackTrace，WrapperException.StackTrace 和 ex.StackTrace 共同构成了完整的 StackTrace。

让例子帮助我们得出答案

有这样一种场景：我希望为各种 ORM 框架提供一种抽象，这可以让应用开发人员自由的在不同的 ORM 实现之间做出选择。

第一个版本的实现

实现伪代码

    interface IRepository<TEntity>
    {
        void Update(TEntity entity);
    }

    class EntityFrameworkRepository<TEntity> : IRepository<TEntity>
    {
        public void Update(TEntity entity)
        {
            throw new EntityFrameworkConcurrentException(); // 可能会抛出这样的异常，这里的代码不是十分准确。
        }
    }

    class NHibernateRepository<TEntity> : IRepository<TEntity>
    {
        public void Update(TEntity entity)
        {
            throw new NHibernateConcurrentException(); // 可能会抛出这样的异常，这里的代码不是十分准确。
        }
    }

有什么问题？

处理并发异常是应用层开发人员的一个非常重要的职责，他们或者选择自动重试、或者选择让用户重试、甚至允许并发带来的不一致性，如果使用了上面的接口问题就大了，应用中该拦截哪种并发异常呢？EntityFrameworkConcurrentException？NHibernateConcurrentException？这样的接口和实现无论如何都达不到：OCP 和 LSP。

将异常作为契约的一部分

实现伪代码

    interface IRepository<TEntity>
    {
        void Update(TEntity entity);
    }

    class ConcurrentException : Exception
    {
    }

    class EntityFrameworkRepository<TEntity> : IRepository<TEntity>
    {
        public void Update(TEntity entity)
        {
            try
            {
            }
            catch (EntityFrameworkConcurrentException ex)
            {
                throw new ConcurrentException(ex);
            }
        }
    }

    class NHibernateRepository<TEntity> : IRepository<TEntity>
    {
        public void Update(TEntity entity)
        {
            try
            {
            }
            catch (NHibernateConcurrentException ex)
            {
                throw new ConcurrentException(ex);
            }
        }
    }

有什么问题？

目前来说还觉得不错，如果 C# 编译器或 CLR 能支持异常契约就好了，Java 虽然支持，但是对于调用者来说又不太友好。

这里给出答案

当异常是契约的一部分时，才需要包装异常。

可能还会有其它答案，等我再思考思考，朋友们也可以给出一些想法。

微软的一个反例

 MethodBae.Invoke

        //   System.Reflection.TargetInvocationException:
        //     调用的方法或构造函数引发异常。
        //
        //   System.MethodAccessException:
        //     调用方没有调用此构造函数的权限。
        //
        //   System.InvalidOperationException:
        //     声明此方法的类型是开放式泛型类型。 即，System.Type.ContainsGenericParameters 属性为声明类型返回 true。
        public abstract object Invoke(object obj, BindingFlags invokeAttr, Binder binder, object[] parameters, CultureInfo culture);

当方法内部抛出异常时，Invoke 会将内部异常给包装起来，这明显不是我们期望的行为，后来微软的 dynamic 调用 和 CreateDelegate 之后使用 Delegate 调用 都修复了这个问题。

备注

最近在读第四版的 clr via c#，确实是一部好书，关于异常作为契约部分的想法，和作者产生了很大的共鸣，书中对异常处理的讲解非常细致，推荐大家读一读这本书。