WCF - Faults / Exceptions versus Messages

Question

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.

Faults come with built in support from WCF where by you can utilize the built in error handlers and react accordingly. This however carries overhead as throwing exceptions in .NET can be quite costly.

Messages can contain neccesary 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 it's contents.

We took a stab at creating a generic message object we could utilize in our services, and this is what we came up with:

public class ReturnItemDTO<T>
{
   [DataMember]
   public bool Success { get; set; }

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

   [DataMember]
   public T Item { get; set; }
}

If all my service calls return this item, I can consistently check the "Success" property to determine if all went well. I then have a Error Message string in the event something went wrong, and a generic item containing a Dto if needed.

Exception information will have to be logged away to a central logging service and not passed back from the service.

Thoughts? Comments? Ideas? Suggestions?

Some further clarification on my question

An issue i'm having with Fault Contracts is communicating business rules.

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".

So do I:

A) use a boolean, throw Fault with message account locked

B) return AuthenticatedDTO with relevant information

Answer 1

This however carries overhead as throwing exceptions in .NET can be quite costly.

You're serializing and de-serializing objects to XML and sending them over a slow network.. the overhead from throwing an exception is negligable compared to that.

I usually stick to throwing exceptions, since they clearly communicate something went wrong and all webservice toolkits have a good way of handling them.

In your sample I would throw an UnauthorizedAccessException with the message "Account Locked".

Clarification: The .NET wcf services translate exceptions to FaultContracts by default, but you can change this behaviour. MSDN:Specifying and Handling Faults in Contracts and Services

Answer 2

I would seriously consider using the FaultContract and FaultException objects to get around this. This will allow you to pass meaningful error messages back to the client, but only when a fault condition occurs.

Unfortunately, I'm in a training course at the moment, so can't write up a full answer, but as luck would have it I'm learning about exception management in WCF applications. I'll post back tonight with more information. (Sorry it's a feeble answer)

Answer 3

The issue i'm having with Fault Contracts is communicating business rules.

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".

So do I:

A) use a boolean, throw Fault with message account locked B) return AuthenticatedDTO with relevant information

Answer 4

Definitely use a FaultContract object - the best practice seems to be an object with a string error message and an in error code. This will allow the client to access the error code to determine the next action, and display a human-friendly message determined by the service as well.