Freigeben über

Avoid Exceptions in Faults

  • Artikel

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

Comments

  • Anonymous
    May 20, 2008
    I've previously talked about using WSDL extensions to provide custom modifications to the WSDL import

  • Anonymous
    May 20, 2008
    What about exceptions in OneWay operations? You can't have FaultContracts with those so what are the best practices with handling exceptions in Duplex services?

  • Anonymous
    May 21, 2008
    Hi nisbus, This advice is independent of the exception handling strategy for a particular message exchange pattern.  It's just saying that when you send another party a failure message, express the content of that message using a CLR-independent description of what went wrong.