WCF基本異常處理模式[上篇]

作者: Artech 來源: 博客園發布時間: 2009-10-27 20:48 閱讀: 8948 次推薦: 0 原文鏈接 [收藏]

　　由于WCF采用.NET托管語言（C#和NET）作為其主要的編程語言，注定以了基于WCF的編程方式不可能很復雜。同時，WCF設計的一個目的就是提供基于非業務邏輯的通信實現，為編程人員提供一套簡單易用的應用編程接口（API）。WCF編程模式的簡單性同樣體現在異常處理上面，本篇文章的主要目的就是對WCF基于異常處理的編程模式做一個簡單的介紹。

　　一、當異常從服務端拋出

　　對于一個典型的WCF服務調用，我個人傾向于將潛在拋出的異常費為兩種類型：應用異常（Application Exception）和基礎結構（Infrastructure Exception）。前者為應用級別，主要體現為執行某個服務操作的業務邏輯拋出的異常；而后者則是業務無關的，通過WCF本身的基礎架構拋出，主要體現在對象的序列化、消息的處理、消息傳輸和消息的分發等等。在這里我們更多地關注與應用異常。

　　首先，我們在不做任何異常處理相關操作的情況下，看看如果在服務端執行某個服務操作的過程中拋出異常后，客戶端會得到怎樣的結果。我們通過實例的形式來演示這中場景。處于簡單和易于理解考慮，我們照例沿用計算服務的例子。

　　我們照例采用典型的四層結構（Contract、Service、Hosting和Client），具體的層次在VS解決方案的劃分如圖1所示：

圖1 異常拋出實例解決方案結構

　　下面代碼片斷表示服務契約（ICalculator）和服務類型（CalculatorService）的定義。為了簡潔，在服務契約接口中，我們僅僅定義了唯一一個用于進行兩個整數觸發預算的方法Divide。服務契約和服務類型類型分別定義在項目Contracts和Services中。

using System.ServiceModel;

namespace Artech.WcfServices.Contracts

{

    [ServiceContract(Namespace = "http://www.artech.com/")]

    public interface ICalculator

    {

        [OperationContract]

        int Divide(int x, int y);

    }   

}

using Artech.WcfServices.Contracts;

namespace Artech.WcfServices.Services

{

    public class CalculatorService : ICalculator

    {

        public int Divide(int x, int y)

        {

            return x / y;

        }

    }

}

　　接下來是通過Console應用程序（Hosting項目）對上面定義的WCF服務（CalculatorService）進行寄宿（Host）的代碼和相關配置。

using System;

using System.ServiceModel;

using Artech.WcfServices.Services;

namespace Artech.WcfServices.Hosting

{

    public class Program

    {

        static void Main(string[] args)

        {

           using (ServiceHost host = new ServiceHost(typeof(CalculatorService)))

            {

               

                host.Open();

                Console.Read();

            }

        }

    }

}

xml version="1.0" encoding="utf-8" ?>

<configuration>  

    <system.serviceModel> 

        <services>

            <service name="Artech.WcfServices.Services.CalculatorService">

                <endpoint address="http://127.0.0.1:3721/calculatorservice" binding="wsHttpBinding" contract="Artech.WcfServices.Contracts.ICalculator" />

            service>

        services>

    system.serviceModel>

configuration>

　　最后在代表客戶端的Console應用程序（Client項目）中對計算服務CalculatorService進行調用。相關的服務調用代碼和配置如下所示，為了讓服務端在執行Divide操作的時候拋出異常，特意將第二個參數設置為0，以便服務在進行除法運算的時候拋出System.DivideByZeroException異常。

using System;

using System.ServiceModel;

using Artech.WcfServices.Contracts;

namespace Artech.WcfServices.Clients

{

    class Program

    {

        static void Main(string[] args)

        {

            using (ChannelFactory channelFactory = new ChannelFactory(

               "calculatorservice"))

            {

                ICalculator calculator = channelFactory.CreateChannel();

                using (calculator as IDisposable)

                {

                    int result = calculator.Divide(1, 0);

                }

            }

        }

}

}

xml version="1.0" encoding="utf-8" ?>

<configuration>

    <system.serviceModel>        

       <client>         

           <endpoint address="http://127.0.0.1:3721/calculatorservice"

              binding="wsHttpBinding" contract="Artech.WcfServices.Contracts.ICalculator" name="calculatorservice" />

        client>

    system.serviceModel>

configuration>

　　在啟動服務寄宿程序（Hosting）后執行客戶端服務調用程序，在客戶端將會跑出如圖2所示的類型為　　System.ServiceModel.FaultException的異常，其錯誤消息為：

　　“由于內部錯誤，服務器無法處理該請求。有關該錯誤的詳細信息，請打開服務器上的 IncludeExceptionDetailInFaults (從 ServiceBehaviorAttribute 或從配置行為)以便將異常信息發送回客戶端，或在打開每個 Microsoft .NET Framework 3.0 SDK 文檔的跟蹤的同時檢查服務器跟蹤日志。”

圖2 客戶端捕獲從服務端拋出的異常

　　從上面的實例演示中，我們可以獲知WCF在默認情況下的異常處理行為：對于服務端拋出的異常（這里主要指應用異常），客戶端捕獲到的總一個具有相同異常消息的System.ServiceModel.FaultException異常。由于異常類型和消息固定不變，對于服務的客戶端來說，直接通過捕獲到的異常相關的信息是無法確定服務端在執行服務操作的時候遇到的具體的錯誤是什么。

　　WCF如此設計的一個主要的目的為了安全。原因很簡單，由于我們不能保證服務端直接拋出的異常不包含任何敏感信息，所以直接將服務端原始的異常信息暴露給客戶端（對于服務提供者來說，該客戶端可能使一個不受信任或者部完全受信任的第三方）。

　　二、異常細節的傳輸

　　通過上面的介紹，我們已經意識到了：在默認的情況下，如果異常（主要指應用異常）在執行服務操作的過程中拋出，其真正的異常信息并不能被客戶端捕獲。實際上，服務端具體的異常細節信息僅限于服務端可見，并不會傳遞到客戶端。

　　然后，不論對于開發階段的調試，還是維護階段的糾錯、排錯，如果在客戶端調用某個服務操作后能夠很直接地獲取到從服務端拋出異常的所有細節，這無疑是一件很有價值的事情。那么，WCF能夠做到這一點呢？答案是肯定的。

　　實際上，對于細心的讀者，看到客戶端捕獲的FaultException異常的消息，就能從中找到解決方案。消息中指出，如果試圖得到服務端具體的錯誤信息，需要開啟IncludeExceptionDetailInFaults這么一個開關。具體來講，又具有兩種等效的方式：配置的方式和應用自定義特性（Custom Attribute）的方式。

　　通過在服務端的配置中，為寄宿的服務定義相應的服務行為（Service Behavior），并把serviceDebug配置項的includeExceptionDetailInFaults屬性設為True。具體配置如下所示：

xml version="1.0" encoding="utf-8" ?>

<configuration>  

    <system.serviceModel> 

        <behaviors>

            <serviceBehaviors>

                <behavior name="serviceDebuBehavior">

                    <serviceDebug includeExceptionDetailInFaults="true" />

                behavior>

            serviceBehaviors>

        behaviors>

        <services>

            <service behaviorConfiguration="serviceDebuBehavior" name="Artech.WcfServices.Services.CalculatorService">

                <endpoint address="http://127.0.0.1:3721/calculatorservice" binding="wsHttpBinding"                    contract="Artech.WcfServices.Contracts.ICalculator" />

            service>

        services>

system.serviceModel>

configuration>

　　大部分系統自定義服務行為都可以直接通過在服務類型上應用System.ServiceModel.ServiceBehaviorAttribute這么一個自定義特性一樣，includeExceptionDetailInFaults服務調試（ServiceDebug）行為也不另外。在ServiceBehaviorAttribute中定義了一個IncludeExceptionDetailInFaults屬性，當我們將ServiceBehaviorAttribute特性應用到具體的服務類型上的時候，只需將此屬性設為true即可。

[AttributeUsage(AttributeTargets.Class)]

public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior

{

    //其他成員    

public bool IncludeExceptionDetailInFaults { get; set; }

}

　　所以如果不采用上面的配置，在服務類型CalculatorService上面應用ServiceBehaviorAttribute特性，并進行如下的設置，也可以到達相同的效果。

using Artech.WcfServices.Contracts;

using System.ServiceModel;

namespace Artech.WcfServices.Services

{

    [ServiceBehavior(IncludeExceptionDetailInFaults = true)]

    public class CalculatorService : ICalculator

    {

        //省略服務成員

}

}

　　當IncludeExceptionDetailInFaults被開啟的ServiceDebug服務屬性通過上述兩種方式應用到我們例子中的服務CalculatorService的情況下，運行客戶端應用程序，將會捕獲包含有錯誤明細信息的異常，運行的結果如圖3所示：

圖3 客戶端捕獲到具有明細信息的異常

　　從圖3中，我們可以看出客戶端捕獲到的實際上是一個泛型的System.ServiceModel.FaultException異常。FaultException繼承自FaultException，這兩種典型的異常類型在WCF異常處理中具有重要的地位，在本章后續章節中還會重點講述，在這里先做一點簡單的介紹。

　　對于所有從服務端拋出的異常，只有FaultException和直接或間接繼承自FaultException的異常才能被序列化，并最終通過消息返回給服務的調用端。FaultException可以通過文本的形式保存相應的錯誤信息。FaultException在FaultException現有的基礎上，增加了一個額外的特性：將錯誤信息通過一個具體的對象表示，其類型便是范型類型TDetail，該對象可以通過屬性Detail設置或者獲取。

[Serializable]

public class FaultException : FaultException

{    

     // 其他成員

    public FaultException(TDetail detail);  

    public TDetail Detail { get; }

}

　　對于上面例子對應的場景，客戶端捕獲的異常類型實際上是FaultException< System.ServiceModel.ExceptionDetail>,也就是說其具體的泛型類型參數為System.ServiceModel.ExceptionDetail。ExceptionDetail的定義如下：

[DataContract]

public class ExceptionDetail

{

    // 其他成員

    public ExceptionDetail(Exception exception);

  

    [DataMember]

    public string HelpLink { get; private set; }

    [DataMember]

    public ExceptionDetail InnerException { get; private set; }

    [DataMember]

    public string Message { get; private set; }

    [DataMember]

    public string StackTrace { get; private set; }

    [DataMember]

public string Type { get; private set; }

}

　　ExceptionDetail是一個數據契約（Data Contract），也就意味ExceptionDetail是一個可以被DataContractSerializer進行序列化的對象。再仔細察看具體的屬性成員列表，我想很多讀者肯定有一種是曾相識的感覺：是不是和System.Exception的屬性成員定義很相似。實際上，ExceptionDetail是WCF專門設計出來用于封裝服務端拋出的異常信息的，其個屬性HelpLink、InnerException和StackTrace各自和System.Exception的同名屬性向對應，而屬性Type表示異常的類型。

　　也就是說，對于應用了開啟IncludeExceptionDetailInFaults的ServiceDebug服務行為的WCF服務，在執行服務操作拋出的異常信息，可以通過包含在客戶端捕獲的FaultException異常中的ExceptionDetail對象獲取。比如，在下面的代碼中，我修改了客戶端的代碼，將具體的錯誤信息輸出到控制臺上：

using System;

using System.ServiceModel;

using Artech.WcfServices.Contracts;

namespace Artech.WcfServices.Clients

{

    class Program

    {

        static void Main(string[] args)

        {

            using (ChannelFactory channelFactory = new ChannelFactory(

               "calculatorservice"))

            {

                ICalculator calculator = channelFactory.CreateChannel();

                using (calculator as IDisposable)

                {

                    try

                    {

                        int result = calculator.Divide(1, 0);

                    }

                    catch (FaultException ex)

                    {

                        Console.WriteLine("Message:{0}", ex.Detail.Message);

                        Console.WriteLine("Type:{0}", ex.Detail.Type);

                        Console.WriteLine("StackTrace:{0}", ex.Detail.StackTrace);

                        Console.WriteLine("HelpLink:{0}", ex.Detail.HelpLink);

                        (calculator as ICommunicationObject).Abort();

                    }

                }

            }

        }

}

}

　　輸出結果：

Message：試圖除以零。

Type：System.DivideByZeroException

StackTrace：   在 Artech.WcfServices.Services.CalculatorService.Divide(Int32 x, Int32 y) 位置 D:\Demos\Artech.WcfServices\Services\CalculatorService.cs:行號 13

   在 SyncInvokeDivide(Object , Object[] , Object[] )

   在 System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object[] inputs, Object[]&; outputs)

   在System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage4(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage3(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage2(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage1(MessageRpc&; rpc)

   在 System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)

HelpLink：

　　注：在catch程序塊中，我們通過代碼（(calculator as ICommunicationObject).Abort();）將會話信道強行中斷。原因在于，對于基于會話信道（Sessionful Channel）的服務調用，服務端拋出的異常會將該信道的狀態轉變為出錯狀態（Faulted），處于Faulted狀態的會話信道將不能再用于后續的通信，即使你調用Close方法將其關閉。在這種情況下，需要調用Abort方法對其進行強行中止。具體的原理，在《WCF技術剖析（卷1）》的第9章有詳細的介紹。

　　對于服務行為SerivceDebug的IncludeExceptionDetailInFaults屬性，我需要再次重申一遍：由于會導致敏感信息泄露的潛在危險，一般地我們僅僅在調試的時候才會開啟該屬性。對于已經發布、付諸使用的服務，這個開關一般是關閉的。實際上，我們從這個服務行為的命名也可以看出，SerivceDebug，也是用于調試服務的服務行為罷了。

　　作者：Artech
　　出處：http://artech.cnblogs.com
　　本文版權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利。

標簽：ASP.NET WCF

文章列表

大師兄

IT工程師數位筆記本

大師兄發表在痞客邦留言(0) 人氣()

E-mail轉寄

IT工程師數位筆記本

If you give someone a program , you will frustrate them for a day; if you teach them how to program, you will frustrate them for a lifetime.IT 這段話的意思是，如果你交給某人一隻程式，你將折磨他一整天;如果你教會某人如何寫程式，你將折磨他一輩子。

BloggerAds