Generic ITransientErrorDetectionStrategy

Topics: Transient Fault Handling Application Block ("Topaz")
Mar 9, 2013 at 5:32 AM
ITransientErrorDetection.IsTransient accepts only an exception and it forces the code to throw exceptions even if not needed. I think it would help having an additional interface defined with a generic type, for example
public interface ITransientErrorDetection<T>
   bool IsTransient(T error);
This way it would still work with the current implementation of retry policy, but also allow cases when the error is not an exception but an error code or message.


Mar 9, 2013 at 6:01 AM
Edited Mar 9, 2013 at 6:02 AM
That's an interesting idea. Feel free to add a suggestion at Uservoice.

My first thought is that the catching of an exception is currently very central to the functioning of the block. The throw of the exception is what triggers the start of the (potential) retry process. So if we aren't using exceptions then how do we know when to test for retry conditions? If the exception is still what triggers the process then how do we know where to get the information (i.e. the <T>) to pass to ITransientErrorDetection?

Now, I'm not saying these are insurmountable issues (I just started thinking about it!) just that it may complicate the design beyond the mandate of the block. Mind you, that's just my initial 2 cents and not canon. It's always possible (likely? :) ) that I don't have the big picture or am overlooking some easy changes.

Also, if you think you need that type of functionality then feel free to modify the source code to suit your needs.

Randy Levy
Enterprise Library support engineer
Support How-to
Mar 9, 2013 at 2:46 PM
Thank you for the reply. I added this suggestion in Uservoice.

The case I have in mind is for applying the retry policy in a HttpMessageHandler and make it a ReliableHttpMessageHandler. If the service returns a status code that would require a retry, the SendAsync will not throw or generate an exception, but the status code containing the HTTP error status code.

Like this case there are many others, where the state of the action execution requires a retry without necessarily throwing an exception.