Passing Serialized Exceptions as Service Faults

One way to pass errors from methods back to a caller is using Exceptions. Unfortunately that doesn't work with services since a caller might be anything and so you shouldn't assume that the client understands the .NET platform (and in particular WCF) as well. Therefore in a service oriented world operations return faults. When implementing a service with WCF you could use the FaultContract() on your service operation. In addition you can also use the ExceptionShielding Attribute on your service implementation. However, ExceptionShielding along with includeExceptionDetailInFaults in the service configuration covers unknown and unhandled exceptions only. Other exceptions are mapped to faults, and that's where your responsibility comes in. Whatever you return to a caller, provide as little information about what happened as possible. For instance you may log an exception to a log file on the server hosting the service and attach a case id to it. Then return that case id as part of the service fault. To get more details about a fault this case id can be used to locate the detailed information in the log file. One thing you definitely shouldn't do is passing the entire exception including call stack in a textual or serialized format to the caller. You don't want to add that additional security risk. The reason you don't want to include too much information in the fault is that an attacker might be able to use the details for future attacks. You don't want to present that information on a SilverPlatter. So for instance you could use the following class for representing faults:

using System.Runtime.Serialization;

namespace AgileTraxx.Services {
 [DataContract]
 public class ServiceResult {
    public ServiceResult(string message, long incidentId) {
       Message = message;
       IncidentId = incidentId;
    }

    [DataMember]
    public string Message { get; set; }

    [DataMember]
    public long IncidentId { get; set; }
 }
}

This class would just take the incident id plus a message. The message could contain information about how to contact support and to note down the incident id. As you can see there is a lot to consider when designing a service interface, including security related factors.