Skip to main content

Invoking System.Actions with Retries using ReliableActionInvoker

 

Although some would argue that Exceptions should be thrown and handled one level up. I tend to think there are plenty of cases where by after an Exception is thrown it makes total sense to Retry the operation N number of times before finally Re-throwing the Exception up the Call stack.

One of these such cases is the simple act of Downloading a file from a Remote Server. Although the code is very simple, WebClient.DownloadFile  can and does fail frequently for a host of different reasons.

Consider the following example which simply tries to download a remote Uri to a local file path.

        private int maxRetries = 5;
        private int retriesCounter;

        public void Download(string uri, string targetFilePath)
        {
            try
            {
                var webClient = new WebClient();

                webClient.DownloadFile(uri, targetFilePath);

                retriesCounter = 0; 
            }
            catch (WebException webEx)
            {
                if (retriesCounter >= maxRetries)
                {
                    throw;
                }

                retriesCounter++;

                Download(uri, targetFilePath);
            }

        }

As you can see with a little bit of Recursion we retry the Operation a maximum of 5 times and then finally Throw the exception.

This type of code is messy to read, very repetitive and also common to errors which can lead to the dreaded StackOverflowException.

To get around this I’ve come up with what I call a ReliableActionInvoker which essentially provides a generic way to Invoke System.Actions and retry them if any Exception or an explicit Exception occurs.

Interface

   public interface IReliableActionInvoker
   {
       /// <summary>
       /// Tries to Invoke the supplied action and if any Exception is thrown will
       /// retry the number of times supplied as maxRetries
       /// </summary>
       /// <param name="action"></param>
       /// <param name="maxRetries"></param>
       void Invoke(System.Action action, int maxRetries);

       /// <summary>
       /// Tries to Invoke the supplied Action and if the Exception is of the 
       /// supplied ExceptionType will retry the number of times supplied as 
       /// maxRetries
       /// </summary>
       /// <param name="action"></param>
       /// <param name="maxRetries"></param>
       /// <param name="exceptionType"></param>
       void Invoke(System.Action action, int maxRetries, Type exceptionType);

       /// <summary>
       /// Tries to Invoke the supplied Action and if the Action throws
       /// an Exception that is contained in the supplied exceptionTypes array
       ///  will retry the number of times supplied as maxRetries
       /// </summary>
       /// <param name="action"></param>
       /// <param name="maxRetries"></param>
       /// <param name="exceptionTypes"></param>
       void Invoke(System.Action action, int maxRetries, Type[] exceptionTypes);
   }

If you’re not familiar with System.Action then I suggest you check it out on MSDN.

Implementation

    public class ReliableActionInvoker : IReliableActionInvoker
    {
        private int retriesCounter;
        public void Invoke(Action action, int maxRetries)
        {
            var exceptionTypes = new Type[0];

            Invoke(action, maxRetries, exceptionTypes);
        }

        public void Invoke(Action action, int maxRetries, Type exceptionType)
        {
            Invoke(action, maxRetries, new[] {exceptionType});
        }

        public void Invoke(Action action, int maxRetries, Type[] exceptionTypes)
        {
            try
            {
                action.Invoke();
                retriesCounter = 0; 
            }
            catch (Exception ex)
            {
                if (retriesCounter >= maxRetries)
                {
                    retriesCounter = 0; 
                    throw; 
                }
                if (exceptionTypes == null || exceptionTypes.Length == 0)
                {
                    retriesCounter++;
                    Invoke(action, maxRetries, exceptionTypes);
                    return;
                }

                if (exceptionTypes.Contains(ex.GetType()))
                {
                    retriesCounter++;
                    Invoke(action, maxRetries, exceptionTypes);
                    return;
                }

                throw;
            }
        }

  }
 

This code is pretty self explanatory. I first call Action.Invoke and catch the Exception. When no Exception Type is supplied then Retry, otherwise check if the caught Exception exists in the supplied Collection and Retry.

When the maxRetries has been reached Throw the Exception.

 

Usage

    public class WebClientDownloader : IUriDownloader
    {
        private readonly IReliableActionInvoker reliableActionInvoker;

        public WebClientDownloader(IReliableActionInvoker reliableActionInvoker)
        {
            this.reliableActionInvoker = reliableActionInvoker;
        }

        public void Download(string uri, string targetFilePath)
        {
            uri.ValidateArgumentNull();
            targetFilePath.ValidateArgumentNull(); 

            var webClient = new WebClient();

            reliableActionInvoker
                .Invoke(() => webClient.DownloadFile(uri, targetFilePath), 5, typeof(WebException));
        }

    }

Finally here’s how you could use it.

That’s all there is to it, it’s pretty simple really. I’m keen here to what you think or how you’ve approached this problem in a generic way before so feel free to comment.

The nice thing about this is it opens up the possibility to implement this using AOP but I’ll leave that to another post.

Till next time. 

Popular posts from this blog

Freeing Disk Space on C:\ Windows Server 2008

  I just spent the last little while trying to clear space on our servers in order to install .NET 4.5 . Decided to post so my future self can find the information when I next have to do this. I performed all the usual tasks: Deleting any files/folders from C:\windows\temp and C:\Users\%UserName%\AppData\Local\Temp Delete all EventViewer logs Save to another Disk if you want to keep them Remove any unused programs, e.g. Firefox Remove anything in C:\inetpub\logs Remove any file/folders C:\Windows\System32\LogFiles Remove any file/folders from C:\Users\%UserName%\Downloads Remove any file/folders able to be removed from C:\Users\%UserName%\Desktop Remove any file/folders able to be removed from C:\Users\%UserName%\My Documents Stop Windows Update service and remove all files/folders from C:\Windows\SoftwareDistribution Deleting an Event Logs Run COMPCLN.exe Move the Virtual Memory file to another disk However this wasn’t enough & I found the most space was

3 Reasons Why Progressive Web Apps (PWAs) Won’t Replace Native Apps

Many people believe Progressive Web Apps (PWAs) are the future of the mobile web, but in my opinion, PWAs are not a replacement for native mobile apps. Here are three reasons why: 1. Native mobile apps provide a smoother & faster experience  Mobile websites, progressive or otherwise are slower and not as smooth. 90% of the time spent is spent using apps vs the browser . The single most significant contributing factor to a smooth experience on mobile is the speed of the network and latency of the data downloaded and uploaded. When you visit websites on desktop or mobile, there is a lot of third-party code/data that gets downloaded to your device, which more often than not has zero impact on the user experience. This includes: CSS (Cascading Style Sheets) JavaScript Ad network code Facebook tracking code Google tracking code The median number of requests a mobile website makes is a shocking  69 . On the other hand, native apps only get the data that is requi

Consuming the SSRS ReportExecutionService from a .NET Client

  I’ve just finished writing a nice wrapper which internally calls the SSRS ReportExecutionService to generate reports. Whilst it was fairly simple to implement there has been some major changes between 2005 and 2008 and the majority of online and documentation is based on the 2005 implementation. The most important change is that the Report Server and Report Manager are no longer hosted in IIS which will be a welcomed change to Sys Admins but makes the security model and hosting model vastly different. So far I’ve yet to figure out how to allow Anonymous Access, if anyone knows how to do this leave a comment and it will be most appreciated. Getting Started To get started you’ll want to add a service reference to http://localhost/ReportServer_SQL2008/ReportExecution2005.asmx where ReportServer_SQL2008 is the name you configure in the Reporting Services Configuration Manager. The Web Application files are located in C:\Program Files\Microsoft SQL Server\MSRS10.SQL2008\R