ServerFault Class

If platform interoperability is not so much an issue and we know we only communicate with other SoapFormatters we can leverage the fact that the SOAP standard explicitly allows non-primitive content within the <detail> element. Ideally we would want the <detail> element to contain the same information an Exception provides, because it is much easier to track down problems with all this data. It would be even better if the detail element was structured like an Exception object to simplify automatic parsing. The easiest solution to produce structured <detail>s would be to serialize an Exception directly into a fault message and this approach works well as long as we only serialize Exceptions defined by the .NET Framework. These exceptions are present on every .NET installation and the receiver can deserialize the Exception object without any problems.

However, applications typically define their own exception classes for specific error scenarios that are not available to the outside world. Serializing these exceptions into a fault message can cause severe problems for receivers that do not have these custom Exception classes available. Now if serializing some exceptions is not an option, how can we populate the <details> with structured data? We serialize a ServerFault object available from the System.Runtime.Serialization.Formatters namespace instead of a custom exception. The ServerFault class defines three properties for the data that identifies an exception (table). A ServerFault serializes the data in a structured fashion within the <detail> of a fault message and every SoapFormatter can deserialize a ServerFault without requiring the any custom assemblies. To make producing fault messages with structured <detail> elements even easier, the SoapFault class provides a constructor overload with a parameter of type ServerFault.

Table The properties of the ServerFault class allow storing and retrieving exception data in a structured format within a Fault’s <detail> element.