tags:

views:

688

answers:

4

Hi ,

I have a WCF service deployed on two or more remote machines and there is a desktop based application that is used by the client to access any wcf service.

The WCF service is connected to SQL server 2005 to read and write data. This is intranet scenario in which client should be on same domain.

Now there can be scenaorios where the wcf service throw exceptiopns: 1. Invalid URL 2. WCF service is down 3. SQL server 2005 is not running 4. client is not on the same domain. 5. Authentication fails 6. Authorization fails and many other exceptions.

and every exception I have to perform some action / update the status bar with apporpriate error occured. For example if autherization fail I have to prompt user to re-enter user credetials etc..

Please suggest me the best design approach to handle this!!

+2  A: 

You can design the specific Fault Data Contracts for each of the exception scenario in your WCF service so that you can handle the fault/exception at client side respectively.

codemeit
I am new to it can you please give me some link
Ashish Ashu
A: 
try
   {
      // Actions
   }
catch (Exception ex)
   {
    // Log the exception
    // Throw Fault Exception back to client
    FaultException fe = new FaultException(ex.Message, new FaultCode("Your fault code"));
    //throw fault exception back to WCF client
    throw fe;
   }
JL
+3  A: 

You can definitely catch and handle all exceptions that happen on your service class and turn them into a FaultException or FaultException exception.

That way, you won't "fault" (or tear down) the communications channel between your client and server.

Even better approach would be to implement the IErrorHandler interface on your service class that provides a way to globally catch all exceptions as they happen and provide a FaultException instead, that's SOAP compliant.

You can even turn your IErrorHandler into a configurable behavior that can be turned on or off in config.

See these articles and blog posts for more details:

Marc

marc_s
I don't know much on IErrorHandler but I read articles and posts on using IErrorHandler it says it has some disadvantages. In some cases exception may directly be thrown from the wcf service to the client. Would you recommend me for IErrorHandler ??
Ashish Ashu
Yes, by all means - I would **always** recommend using IErrorHandler. Can you post the links to these articles that say it has disadvantages?? Never heard of those - I'd like to investigate....
marc_s
http://stackoverflow.com/questions/265551/wcf-errorhandlerRead the second post!! I don't know wheather it's correct or not but it always creates the confustion in my mind
Ashish Ashu
Well, I guess he's expecting too much - IErrorHandler will catch all exceptions that occur ON THE SERVER - a communications error, or a mismatch in security settings, does not happen on the server - but before the message even reaches the server. This is a different scenario.
marc_s
+3  A: 
  1. Create a custom fault class that is marked with the DataContract attribute
  2. Mark the method on the service contract interface with FaultContract. Ie. [FaultContract(typeof(CustomFault))]
  3. In your service method, catch any applicable internal exceptions and throw a FaultException<CustomFault>. Alternatively, as marc_s mentioned, you can use IErrorHandler to map the exception to the fault.

Personally, I create a base Fault class that has a Reason property and I extend all custom faults from this class. When I want to throw the fault, I call:

throw Fault.Create<CustomFault>(new CustomFault("Boo hoo"));

It's also worth noting that I version my fault classes (including the common Fault class) along with all my other services. This is only a concern if service versioning is a concern, though.

Here's the basic Fault class (I've removed argument validation for brevity):

[DataContract(Namespace = XmlVersionNamespace.FaultNamespace)]
public abstract class Fault
{
    internal FaultReason Reason { get; set; }

    protected Fault(string reasonText)
    {
        Reason = new FaultReason(new FaultReasonText(reasonText, CultureInfo.CurrentUICulture));
    }

    public override string ToString()
    {
        return Reason.ToString();
    }

    internal static FaultException<TDetail> Create<TDetail>(TDetail fault) where TDetail : Fault
    {
        return new FaultException<TDetail>(fault, fault.Reason);
    }
}
Richard Szalay
Thanks Richard ! Can you please give me an example if suppose authentication fails. Just give me the class relation ships and how you will handle on client app..
Ashish Ashu
I would create an AuthenticationFailedFault (extend it from Fault), passing a message to the base Fault constructor. In your client app, you just catch FaultException<AuthenticationFailedFault>, since AuthenticationFailedFault will be part of the WSDL (as long as you marked the method with [FaultContract])
Richard Szalay