Faults and Exception Handling

A regular .NET exception is a CLR construct with a stack trace, an object type, and potentially a reference to internal objects — none of which mean anything to a client that might not even be running on .NET, such as a Java or JavaScript client calling over SOAP or REST. Because of this, WCF never lets a raw exception cross the wire; by default, an unhandled exception thrown from a service operation is caught by the runtime and converted into a generic FaultException with a message like 'The server was unable to process the request due to an internal error,' deliberately stripped of details to avoid leaking implementation internals or sensitive data to callers. You can opt into richer diagnostics during development by setting <serviceDebug includeExceptionDetailInFaults="true"/> in the service behavior configuration, which includes the full exception type and stack trace in the fault — but this should never ship to production, since it hands attackers a roadmap of your internal implementation.

When you want a client to be able to catch a specific, structured error — say, an OrderValidationFault carrying an error code and a list of invalid fields — you declare it explicitly with [FaultContract(typeof(OrderValidationFault))] on the operation contract, define OrderValidationFault as a DataContract-decorated class, and throw it from the service using throw new FaultException<OrderValidationFault>(fault, reason) rather than throwing OrderValidationFault directly. This is deliberate: FaultContract is part of the service's public interface, documented in the WSDL/metadata just like the operation's parameters and return type, which means clients generated from that metadata get a strongly typed way to catch FaultException<OrderValidationFault> and inspect its Detail property, instead of parsing a generic error string.

Sprinkling try/catch blocks with FaultException throws inside every operation gets repetitive and inconsistent across a large service. Implementing System.ServiceModel.Dispatcher.IErrorHandler lets you centralize this: HandleError(Exception error) is called for every unhandled exception (a good place to log it, since this runs regardless of whether the client gets details), and ProvideFault(Exception error, MessageVersion version, ref Message fault) lets you inspect the exception type and construct the exact SOAP fault message to send back — for instance, converting any SqlException into a generic 'service temporarily unavailable' fault while converting a custom ValidationException into a properly typed FaultException<OrderValidationFault>. You register the error handler via a custom IServiceBehavior applied through an attribute or through configuration, which keeps operation code focused purely on business logic instead of fault translation plumbing.

Beyond the message-level fault sent to the client, receiving certain kinds of errors — particularly unhandled exceptions that aren't converted to a well-formed FaultException, or lower-level communication errors like a timeout — can put the WCF channel itself into a Faulted state (ICommunicationObject.State == CommunicationState.Faulted). A faulted channel cannot be reused for further calls; calling Close() on a faulted channel throws a CommunicationObjectFaultedException, so the correct client-side pattern is to check the exception type in a catch block and call Abort() instead of Close() when a fault or communication exception occurs, then create a brand-new channel/proxy for subsequent calls. This is a classic WCF pitfall: developers who wrap every client proxy in a using block get bitten because Dispose() internally calls Close(), which throws a second exception that masks the original one if the channel already faulted.