.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#，确实是一部好书，关于异常作为契约部分的想法，和作者产生了很大的共鸣，书中对异常处理的讲解非常细致，推荐大家读一读这本书。