Avoid Exceptions in Faults
FaultException supports both an untyped variant, for when you don't have any particularly interesting detail to provide, and a typed variant, for when you do. Don't use a subclass of Exception as the type of a typed FaultException. Here's why.
When you use a typed FaultException, you are creating a fault contract between the client and service about data that gets exchanged and a common type system that the two share. By using a CLR exception type, you are unnecessarily forcing that common type system to reflect details of the CLR type system. That type dependency will make it more complicated in the future to move your services and clients to other platforms and possibly even to other versions of the framework. When moving to another version of the framework, you may change the exception profile of your application and start receiving exception types that are more specific or different than the exception types that you received before for a particular error. If you pass those exceptions through to the client, then those platform implementation details are now leaked across the service boundary. Finally, there's no guarantee that the interesting information in a CLR exception will be preserved across the boundary. Most of the interesting contents of exceptions are not serializable.
Instead of creating a FaultException with a subclass of Exception, you should define a fault contract that is meaningful for your application or business user. This fault contract can be crafted according to the needs of your service and will remain independent of any particular platform or technology choices that you may need to make later.
Next time: Faster Known Types in Orcas
