Handling Message Encoder Errors

This time it's two questions that have the same answer.

What contract does the message encoder have for producing a message from ReadMessage?

What should the transport do if the message encoder doesn't produce a message from the buffer you give it?

The contract of the message encoder is that it will always either throw an exception or produce exactly one message each time ReadMessage is called. This means that a properly-written message encoder will never fail to produce a message without throwing an exception out of ReadMessage for the transport to handle.

As you might recall, the contract that the transport must abide by is that operations should only throw exceptions that are subtypes of CommunicationException, TimeoutException, or some fatal exception type (such as OutOfMemoryException). The transport should catch all exception types that it knows the message encoder will produce, such as XmlException, and wrap those in some instance of CommunicationException. A good choice would be ProtocolException. However, the transport should not just eat all types of exceptions. It's best to let a stray exception through unless it is a specific, known type because you run the risk of trapping a fatal exception.

What happens to the message after the transport gets it back from the message encoder is no longer constrained by the contract of the message encoder.

Next time: How to Configure MaxItemsInObjectGraph

Comments

• Anonymous
  November 13, 2006
  When you call receive on a channel, there is always a timeout that bounds that receive operation. There

• Anonymous
  November 18, 2006
  I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available

• Anonymous
  October 20, 2007
  I have lots of stuff collected up today. Software Architecture/SOA Arnon Rotem-Gal-Oz has made available