title: WCF - Faults / Exceptions versus Messages
body: <p>We're currently having a debate whether it's better to throw faults over a WCF channel, versus passing a message indicating the status or the response from a service.</p>
  
  <p>Faults come with built-in support from WCF where by you can use the built-in error handlers and react accordingly. This, however, carries overhead as throwing exceptions in .NET can be quite costly.</p>
  
  <p>Messages can contain the necessary information to determine what happened with your service call without the overhead of throwing an exception. It does however need several lines of repetitive code to analyze the message and determine actions following its contents.</p>
  
  <p>We took a stab at creating a generic message object we could utilize in our services, and this is what we came up with:</p>
  
  <pre><code>public class ReturnItemDTO&lt;T&gt;
  {
      [DataMember]
      public bool Success { get; set; }
  
      [DataMember]
      public string ErrorMessage { get; set; }
  
      [DataMember]
      public T Item { get; set; }
  }
  </code></pre>
  
  <p>If all my service calls return this item, I can consistently check the "Success" property to determine if all went well. I then have an error message string in the event indicating something went wrong, and a generic item containing a Dto if needed.</p>
  
  <p>The exception information will have to be logged away to a central logging service and not passed back from the service.</p>
  
  <p>Thoughts? Comments? Ideas? Suggestions?</p>
  
  <p><strong>Some further clarification on my question</strong></p>
  
  <p>An issue I'm having with fault contracts is communicating business rules.</p>
  
  <p>Like, if someone logs in, and their account is locked, how do I communicate that? Their login obviously fails, but it fails due to the reason "Account Locked".</p>
  
  <p>So do I:</p>
  
  <p>A) use a boolean, throw Fault with message account locked</p>
  
  <p>B) return AuthenticatedDTO with relevant information</p>