Handling retries part 4 – using both OOP & functional programming

Handling retries part 1 – using inheritance

Handling retries part 2 – using composition

Handling retries part 3 – using functional


In our line of work there are usually many ways to accomplish a particular task (for better or worse), in these series of posts I want to try and demonstrate various different techniques that we can use and also what benefits we can gain from each.

So without further ado here is the scenario I want to be able to support:

I need a way of performing a particular action that can also handle an exception being raised by re-trying the action after a specified amount of time for a specified number of retries.

here is the pseudo-code to get an idea:

set retries = 5
    while retries > 0
            call task
            exit while
            decrement retries
            call exception
        call sleep 3
    end while
call failure

The most basic way to accomplish this would be to simply have the C# replicate exactly what we have above and this would do the trick but means that if we had other tasks that needed to behave the same way we would end up duplicating the code for every instance ideally we want to re-use this behaviour.

Having the best of both worlds

In the last part we had a couple of issues with using just a functional programming (FP) approach (certainly in C#, full FP languages have dealt with these issues)

Lets deal with the client duplication issue first, ideally what we would like is that we can have the FP retry behaviour but to have it wrapped up in an object that can be re-used:

public class RetryInstance
    public TimeSpan Interval { get; set; }    
    public int Retries { get; set; }    
    public Action<Exception> OnException { get; set;}    
    public Action OnFailure = { get; set; }    
    public void Execute(Action action)    
        var retryCount = this.Retries;        
        while (retryCount > 0)        
            catch (Exception ex)            

This would be used like this:

var retryInstance = new retryInstance()
    Interval = TimeSpan.FromSeconds(30),    
    Retries = 5,    
    OnException = ex => Log.Error(ex),    
    OnFailure = () => Log.Fatal("fail!")
// later in the code
retryInstance.Interval = TimeSpan.FromMinutes(1);

Here we have moved the FP code into an RetryInstance object we can the use this object to maintain the state of how we want the retries, intervals, callbacks to behave and in the example we can adjust this when we need to without having to duplicate anything. The readability of the code has improved quite a lot as well, but I think we can go one step better by introducing a Builder object to help us build a RetryInstance and also to provide it with suitable defaults:

public class RetryConfiguration
    private TimeSpan _interval;    
    private int _retries;    
    private Action<Exception> _onException;    
    private Action _onFailure;    
    public void SetInterval(TimeSpan duration)    
        _interval = duration;    
    public void SetRetries(int count)    
        _retries = count;    
    public void WhenExceptionRaised(Action<Exception> handler)    
        _onException = handler;    
    public void WhenFailed(Action handler)    
        _onFailure = handler;    
    public RetryInstance Build()    
        return new RetryInstance()        
            Retries = _retries,            
            Interval = _interval,            
            OnException = _onException,            
            OnFailure = _onFailure        
public static class RetryFactory
    public static RetryInstance New(Action<RetryConfiguration> configuration)    
        config = new RetryConfiguration();        
        config.WhenExceptionRaised(_ =>; {}); // no-op        
        config.WhenFailed(() =>; {}); // no-op        
        return config.Build();    

This would then be used by client code like this:

RetryFactory.New(cfg =>                
        cfg.WhenExceptionRaised(ex => Log.Error(ex));                    
        cfg.WhenFailed(() => Log.Fatal("fail!"));                

We have introduced a couple more objects one is a configuration object that exposes a really nice API to setup our RetryInstance object and the other is our builder object/fluent DSL that exposes a static method to create a new RetryInstance and also provides our suitable defaults that we can choose to override.


We have certainly covered a lot of ground in these series of posts and have ended up with quite a lot of options for how we could solve the issue in the introduction and there are no doubt way more other ways that I couldn’t think of! Some of these may be overkill especially for the simplistic case of retry behaviour we have been looking at as with most design & architecture its always a balance and this goes hand in hand with how the behaviour is going to be used. Here is a breakdown of how I would personally go about deciding how to implement the retry behaviour:

  • If I have one object that has one single use for using retry logic I would probably stick to a simple method call like the pseudo-code in the introduction
  • Once I have another use in a separate object I may decide to use inheritance (if no inheritance hierarchy is present) or move to using composition (decorator pattern if I don’t want the object to manage the retries)
  • If I start to have lots of objects wanting retry behaviour and especially across different projects that’s when I would probably move to using OOP & FP together to provide the callers with a nice API to use and to also reduce the amount of code they need to write in order to use it

I hope that this series has helped to put forward the case that we should be open to various different ways of designing software to solve problems and just because in the past you have always done it one way it doesn’t mean that you should then apply that across the board as each problem tends to unique.