Creating a WCF webservice with a single standard response object

I've been asked to implement a webservice using WCF that will return a single standard response object that indicates whether the webservice call succeeds or fails and an error message if one occurs.

It looks to me like this is not how WCF is intended to be used, is that correct?

My problem is that I am using IDispatchMessageInspector.AfterReceiveRequest() to validate the request against an XSD prior to WCF deserializing it and calling my operation.

If it fails validation how do I return my standard response object? WCF seems to want me to throw a FaultException in this scenario but I want the interface to purely return one standard response object that contains any failure information.

So this would mean that you need to define both a custom Fault Exception that you can throw when the request you receive fails validation prior to deserialization etc, and the second standard response to send when the request succeeds.

Is that the right approach?

To achieve my goal of simply returning the one single response object if something like a validation error occurs, I've been trying to cheat and set the request object to null in AfterReceiveRequest() so it skips processing of the request.

 object IDispatchMessageInspector.AfterReceiveRequest(ref System.ServiceModel.Channels.Message request, System.ServiceModel.IClientChannel channel, System.ServiceModel.InstanceContext instanceContext)
        {
            try
            {
                validateMessage(ref request);
            }
            catch (Exception e)
            {
                request = null;
                return new FaultException<string>(e.Message);
            }
            return null;

        }

and then perhaps I can create my own custom response object in BeforeSendReply().

 void IDispatchMessageInspector.BeforeSendReply(ref System.ServiceModel.Channels.Message reply, object correlationState)
        {
            if (correlationState != null)
            {
                reply = CreateMyOwnResponse(((FaultException) correlationState));
            }
        }

But I know that this seems silly and is working against开发者_开发知识库 how WCF is meant to be used most likely. Is there a way to nicely achieve what I want or do I have to send an exception type when things go bad and a different "normal" response when things succeed?

---

WCF does not restrict the return object or force you to throw exceptions to communicate errorenous conditions. It depends on your needs and agreements you make on an overall scale in your architecture.

In my applications, I always tend to have an int type return argument that goes negative when an error occurs and is zero when the operation is completed successfully. You can also have more complex return arguments that have error structures in them, like:

[DataContract]
public class ReturnValue
{
  [DataMember]
  public int ReturnCode;

  [DataMember]
  public string ResultingDescription;

  // enum listing severities like Critical, Warning, etc.
  [DataMember]
  public Severity Severity;
}

If you need complex returned parameters as returns of your operation you could have the following signature:

[OperationContract]
ReturnValue MyOperation (int param1, string param2, out MyOperationResult result);

My rule of thumb is:

1. Only throw an exception over service boundaries for unexpected and unhandled exceptions (things you didn't expect at time of development)

2. For all other situations, return an error code using the return value of your operation (it is not an exception with that respect)