WCF基础教程之异常处理：你的Try..Catch语句真的能捕获到异常吗？

　　在上一篇WCF基础教程之开篇：创建、测试和调用WCF博客中，我们简单的介绍了如何创建一个WCF服务并调用这个服务。其实，上一篇博客主要是为了今天这篇博客做铺垫，考虑到网上大多数WCF教程都是从基础讲起的，大家平时工作可能只是去调用和修改WCF的一些方法，而并未创建和配置过WCF，如果大家通过网上的教程去一步一步的创建和配置WCF，中途遇到错误，特别是WCF的配置这块很容易出错，难免会浪费时间。今天，我们就主要来说一下WCF中服务端和客户端的异常处理。

 一、WCF异常处理机制

　　接着昨天的例子，我们在UserService中添加一个新的方法，或者直接修改DoWork方法，抛出一个异常，代码如下：

　　　　[OperationContract]
        public void GetMessage()
        {
            throw new Exception("System Error！");
        }

下面，我们在客户端调用这个方法，代码如下：

  public void GetData()
        {
            UserServiceReference.UserServiceClient client = new UserServiceReference.UserServiceClient();
            client.GetMessageCompleted += client_GetMessageCompleted;
            client.GetMessageAsync();
        }

        void client_GetMessageCompleted(object sender, System.ComponentModel.AsyncCompletedEventArgs e)
        {
             if(e.Error != null)
            {
                MessageBox.Show(e.Error.Message);
            }
        }

这里值得注意的是，在异步方法执行完成后，参数e会携带WCF抛出的异常信息，保存在e.Error中。下面我们按下F5，来执行看看会发生什么,如图：

首先我们看到的是VS在WCF服务端捕获到了异常，因为我们用的是Debug模式，这里可以看到详细的异常信息，“System Error”，按F5继续走，会看到如下图：

到这里，我们看到已经到了客户端，已经看不到异常详细了，继续按F5,向后走，看到弹出如下消息框，如图：

看到这个异常信息，完全不知道WCF哪里出现错了，对于修复Bug的程序员来说无疑是一个噩梦。

从上面的实例演示中，我们可以获知WCF在默认情况下的异常处理行为：对于服务端抛出的异常（这里主要指应用异常），客户端捕获到的总一个具有相同异常消息。由于异常类型和消息固定不变，对于服务的客户端来说，直接通过捕获到的异常相关的信息是无法确定服务端在执行服务操作的时候遇到的具体的错误是什么。

根据微软MSDN的文档：https://msdn.microsoft.com/zh-cn/library/dd470096(VS.95).aspx，在web项目中添加SilverlightFaultBehavior类，其代码如下：

public class SilverlightFaultBehavior : Attribute, IServiceBehavior
   {
      private class SilverlightFaultEndpointBehavior : IEndpointBehavior
      {
         public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
         {
         }

         public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
         {
         }

         public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
         {
            endpointDispatcher.DispatchRuntime.MessageInspectors.Add(new SilverlightFaultMessageInspector());
         }

         public void Validate(ServiceEndpoint endpoint)
         {
         }

         private class SilverlightFaultMessageInspector : IDispatchMessageInspector
         {
            public object AfterReceiveRequest(ref Message request, IClientChannel channel, InstanceContext instanceContext)
            {
               return null;
            }

            public void BeforeSendReply(ref Message reply, object correlationState)
            {
               if ((reply != null) && reply.IsFault)
               {
                  HttpResponseMessageProperty property = new HttpResponseMessageProperty();
                  property.StatusCode = HttpStatusCode.OK;
                  reply.Properties[HttpResponseMessageProperty.Name] = property;
               }
            }
         }
      }

      public void AddBindingParameters(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase, Collection<ServiceEndpoint> endpoints, BindingParameterCollection bindingParameters)
      {
      }

      public void ApplyDispatchBehavior(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
      {
         foreach (ServiceEndpoint endpoint in serviceDescription.Endpoints)
         {
            endpoint.Behaviors.Add(new SilverlightFaultEndpointBehavior());
         }
      }

      public void Validate(ServiceDescription serviceDescription, ServiceHostBase serviceHostBase)
      {
      }
   }

然后，修改UserService的代码如下：

然后，我们在UserService上面，点击鼠标右键，在浏览器中预览一下，然后再客户端上的UserServiceReference上面，点击右键，更新服务引用，然后我们按Ctrl + F5,以release模式运行项目(这样不会中断)，如图：

我们看到，这次显示了不同的错误，但是依然没有抛出真正的异常信息，我们还是不知道哪里出现错了。不过根据提示消息，我们可以看到解决办法，然后打开webConfig，寻找includeExceptionDetailInFaults，果然有这个配置，如图：

我们修改includeExceptionDetailInFaults的值为true,然后再执行，我们看到了如下信息：

哈哈，终于看到真正的异常信息了。

下面再来说一种方法，不修改webconfig文件，如图：

当然，我们也可以完整的将WCF的异常的抛给客户端(服务端不做任何错误处理)，但是这样可能会泄露一些敏感信息，并不安全。更多关于WCF异常处理的信息，可以参考园内大牛的博客：

WCF技术剖析之二十一: WCF基本的异常处理模式[上篇]

WCF技术剖析之二十一：WCF基本异常处理模式[中篇]

WCF技术剖析之二十一：WCF基本异常处理模式[下篇]

 二、客户端的调用WCF和异常处理

　　下面，我们修改客户端代码，添加一个代理类，来对WCF的调用进行一些封装，关于WCF中使用回调函数，可以参考我之前的这篇博客Silverlight中异步调用WCF服务，传入回调函数，代码如下：

这里客户端的异常e.Error可以通过回调函数传递给页面，然后做处理。然后，我们修改UserService，如图：

然后，更新服务引用，我们调用这个WCF方法，加上Try...Catch...,大概就变成了下面这个样子，如图：

这时我们按下F5运行，会看到弹出了我们返回的结果："WCF Result"。

下面我们在显示结果前加些代码，如图：

然后，F5运行，猜猜会出现什么情况，按照我们所想的，应该是弹出一个消息框，对吧，但是，实际情况是这样的，如图：

咦，为什么我们写的Try...Catch...没有捕获到异常呢？代码明明在Try...Catch...里面啊~~，到这里，我想你们应该清楚我这边博客标题的含义了吧~~

如果之前一直是这样的写的，以后就要赶紧改啦~~

其实，我们出现异常的这段代码，是通过一个Lamda表达式传进来的一个匿名委托，相当于一个独立的方法，所以这个方法根本就不在你的Try...Catch...的作用域内。(说的不对，还请指正)。

所以，将Try...Catch...写到内部就可以了，修改代码如下，就可以了，如图：

到这里，就算是说完了。这里提醒一下大家以后写代码，测试的时候一定要下断点全部走到，特别是异常处理部分。最后，祝大家工作愉快，欢迎加入QQ交流群，一起学习交流。

作者：雲霏霏

QQ交流群：243633526

博客地址：http://www.cnblogs.com/yunfeifei/

声明：本博客原创文字只代表本人工作中在某一时间内总结的观点或结论，与本人所在单位没有直接利益关系。非商业，未授权，贴子请以现状保留，转载时必须保留此段声明，且在文章页面明显位置给出原文连接。

如果大家感觉我的博文对大家有帮助，请推荐支持一把，给我写作的动力。