WCF Exceptions and faults

The exception handling is an integral part of any application. It depends on the situations and the severity of the exception that defines what we want to do with the exception. When working on webservices, especially while interacting with third party application, I always thought its better idea to catch any exception in method and return that as string. But this doesn’t really work if we have to return some other datatype and also we need to insist client apps to check for Error string to get the error message. There are chances that client apps don’t care about the Error string that was returned by service. So the exception thrown on service will still be treated as valid process on the client apps.


When I started working with WCF, I could find different ways to handle the exceptions.

• Catch the exception on service and return as string. (I have already explained what the part of using this way)

• Throw the exception directly. But how does this effect on client apps

• And convert the exceptions to Faults which client apps can understand.

Let’s see if throwing exceptions on service really help us

If there is any exception on wcf service, the client app will always receive a fault exception as “The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.” This does not provide any information about the exception. If we enable the detail on server , it will expose implementation details to the client.

As a summary exposing exceptions to client has many limitations, so it’s always a better idea to map the exceptions on the wcf service to faults and let the client apps to deal with it.