The Try-Catch-Abort Pattern

The simplest programming patterns are those that don't require a lot of thought to apply the pattern. The way that you can get to one of these simple programming patterns is to smooth out the rough edges until almost every interesting case can be handled by a direct application of the pattern. The client communication objects that you commonly use with WCF have one of these simple patterns.

 try
{
   // Use the thing
   ...
   thing.Close();
}
catch (TimeoutException)
{
   thing.Abort();
}
catch (CommunicationException)
{
   thing.Abort();
}

I refer to this as the Try-Catch-Abort pattern because that's the distinctive sequence of elements that appear in the code. The normal path is for client objects to be used for a while and then gracefully closed. The abnormal path is for something to go wrong with the client object. Once the client object is no good, it is no longer possible to perform a graceful close. Instead, it is mandatory to perform an ungraceful shutdown by aborting the client object.

However, what does it mean for the client object to not be good? There are two classes of expected exceptions to come out of client objects: TimeoutException and CommunicationException. There are unexpected exceptions that can come out of client objects but you shouldn't try to handle those because they weren't expected. Even the expected exceptions are things you can't handle unless you know something more specific about what went wrong. You need more information, such as recognizing a specific exception type, before you can understand the semantics of the exception, such as whether trying again is likely to succeed.

There is a particularly useful bit of information that you can look at in this case but I see very few people doing it in their programs. That useful bit of information is to look at the State property of the communication object. The state of a functional communication object is Opened. This is the only state where sending messages is valid. Every other state indicates that the communication object is not currently functional. When deciding how to treat the object after an exception, examining the communication state is a crucial data point for making that decision. Not every exception will invalidate the communication object. However, once a client object is no good, there is nothing you can do with it but abort it and throw it away.

Next time: Optimizing MSMQ

Comments

• Anonymous
  May 04, 2007
  After an earlier article about receiving messages , Kenny Wolf suggested that I talk about the exception

• Anonymous
  May 04, 2007
  There is something more conceptual in the try, some people things this is valid: if ihaveconnectionwithserver //use the thing else error I have seen that a lot of times. But... ¡you know that a call is valid only in that call! So is wrong to think that you can know earlier. It is so important to trust only in the call to know if it has been OK. Good blog.