WCF technical Analysis of 24: Servicedebugbehavior service behavior is how to achieve the spread of abnormal?

The service side only throws the faultexception exception to be properly serialized into a fault message and is propagated to the client. For general exceptions (such as the dividebyzeroexception that are thrown by the divide operation), the exception information cannot be delivered to the client by default. However, if you apply a service behavior such as Servicedebugbehavior to a service and turn on the includeexceptiondetailinfaults switch, the exception information will be propagated to the client intact. How does the WCF internally handle the thrown FaultException exception?

In fact, WCF's handling of faultexception exceptions is not complicated, so let's take a quick look at the related process: if you throw a faultexception exception during the execution of a service operation, WCF will first determine Includeexceptiondetailinfaults Development is open, if not, WCF will create a Messagefault object manually, And the language culture of the current thread gets a fixed amount of text from the resource file as Messagefault's Faultreason (the paragraph we saw in the WCF basic exception handling pattern [Previous] example). In addition, the fixed FaultCode is created as the code for the Messagefault. Eventually, WCF converts the Messagefault to a fault message and takes a fixed action as the action header for the message. So, no matter what exception the server throws, the client catches a faultexception exception that always has the same information.

Note: the client's error message is always this paragraph: "The server was unable to process the request due to an internal error." For more information about this error, open the Includeexceptiondetailinfaults on the server (from ServiceBehaviorAttribute or from <serviceDebug> configuration behavior) To send exception information back to the client, or to check the server trace log while opening the trace for each Microsoft. NET Framework 3.0 SDK document. ”

It says that the includeexceptiondetailinfaults switch is off. If Includeexceptiondetailinfaults is turned on, WCF creates the Exceptiondetail object based on the exception object and creates the Messagefault as a detail object (with a fixed faultcode). Eventually, the Messagefault transformation is generated fault messages, and of course the action takes a fixed predetermined value. Therefore, in this case, the information thrown by the server can always be passed intact to the client. A generic faultexception<exceptiondetail> exception is always captured by the client.

Why can a Exceptiondetail object be deserialized?

For the exception object serialization and deserialization work, eventually all fall back on the Faultformatter such an object (concrete principle, can refer to "In-depth analysis WCF bottom exception processing framework implementation principle [Medium]"). Whether it is virtual or deserialization, there is a fundamental premise: determining the type of object. Faultformatter relies on a faultcontractinfo list specified at creation time to learn the specific type, which originally came from the definition of the Faultcontractattribute attribute applied on the action method.

So, for applying the Servicedebugbehavior service behavior and opening up the includeexceptiondetailinfaults scene, How can the client generate the Exceptiondetail object by deserializing the XML fragment that represents the error detail in the hosting and fault messages? Since we have not applied the Exceptiondetail type to the corresponding action method through the Faultcontractattribute attribute, Faultformatter cannot determine the type of the deserialized object, so it is not possible to say that deserialization is unsuccessful.

The reason is simply that WCF creates the Faultcontractinfo object based on the Exceptiondetail type when initializing the Faultformatter and adds it to its own Faultcontractinfo list. The corresponding implementations can basically be represented by the following pseudocode:

   1:internal class Faultformatter:iclientfaultformatter, Idispatchfaultformatter
   2: {
   3:     //other Members
   4:     private faultcontractinfo[] Faultcontractinfos;
   5:     Internal faultformatter (synchronizedcollection<faultcontractinfo> faultcontractinfocollection)
   6:     {
   7:         list<faultcontractinfo> list= new list<faultcontractinfo> (faultcontractinfocollection);
   8:         Faultcontractinfocollection.add (New Faultcontractinfo ("http://schemas.microsoft.com/net/2005/12/ Windowscommunicationfoundation/dispatcher/fault ", typeof (Exceptiondetail)));
   9:         This.faultcontractinfos = list. ToArray ();
  :     }    
  11:}

What if you throw a faultexception<exceptiondetail> exception directly?

Since Faultformatter can automate serialization and deserialization based on Exceptiondetail objects, it means that we can throw the faultexception<exceptiondetail directly in a specific service operation > exception, and no longer need to apply Exceptiondetail as an error contract type to the corresponding service operation by Faultcontractattribute attribute. Also take our computing services for example, in the Divide method we use the Exceptiondetail package to encapsulate the exception thrown in the operation, and finally throw the faultexception<exceptiondetail> exception.

   1:using System.ServiceModel;
   2:using Artech.WcfServices.Contracts;
   3:using System;
   4:namespace Artech.WcfServices.Services
   5: {
   6:     [ServiceBehavior (namespace= "http://www.artech.com/")]
   7: Public     class Calculatorservice:icalculator
   8:     {
   9: Public         int Divide (int x, int y)
  %:         {
  One:             try
  :             {
  : Return                 x/y;
  :             }
  :             catch (Exception ex)
  :             {
                   throw new Faultexception<exceptiondetail> (ex), ex. message);
  :             }
  :         }
  :     }
  21:}