How should a WCF service implementation handle errors/faults without coupling to FaultContract

Question

I understand the concept of Fault Contracts in WCF, but they seem to be tightly coupled to WCF and SOAP in particular. I've created a set of services that are separate from the contract definitions and the implementations could be used in many ways, not just WCF/SOAP. For instance, if I wanted to create a RESTful service, or just use the services implementation directly from an application.

But now I'm working on error handling and it seems that as soon as I introduce FaultContract and FaultException into the service code, I'm now tightly bound to SOAP services. In my case, SOAP is the target wire format right now, and so I want to produce a SOAP fault.

What methods are people using in WCF to produce SOAP faults, but not couple the implementation to FaultContract?

Answer 1

Use FaultContract in operations if you want to throw expected exception. You will get some small set of FaultContracts used in your operations. When you need to add non SOAP endpoint you can use IErrorHandler implementation in custom endpoint behavior and convert thrown FaultExceptions to format you need. Here you have some example for JSON.

Answer 2

For decoupling error handling from your service implementation, have your service implement IErrorHandler. This allows you to throw standard .NET exceptions in your service code. The IErrorHandler behavior translates them to SOAP faults at the service level.

There's lots of examples on the web. The one I like most is here because I actually made the same mistake with fault actions that he points how to fix.