Any type of integration relies on an IO operation that often out of control of the developer, we use web services that can go down, open and read files from remote servers that can be suddenly inaccessible, rely on database connections that can drop. Adding code to deal with this has always been essential to any integration module.
As an example I have created small console application that opens and reads an excel file, that is already open causing an IOException. I will add the Polly library to this and set up a policy to retry the operation while prompting the user to close the file.
What is Polly?
Polly is a library that provide a wrapper around various fault handling and resilience functions, which are frequently created in any application that has to deal with IO operations. In the same way that you could add your own code for error and debug logging, or you could just more easily add something like log4net, Polly is a very well supported and full featured library that can easily do a lot of that heavy lifting for you.
- Catch exceptions and retry an operation
- Caching requests
- Circuit breaking if system is being overloaded
- Bulkhead isolation – isolating system faults from one another.
Reading an excel spreadsheet that is open
For this example I am going to start with some very simple code, that tries to open an excel file called Jam2 (more jam so an improvement on the mark 1 version :-)). Unfortunately this file is open and we need to prompt the user to close it so that we can read the contents and do something with it.
Dealing with exceptions using Polly
We don’t need to add much to get this working with Polly, and granted in this example adding Polly is a bit over the top.
First of all we create a Policy object, catching any IOException and retrying 3 times, each time prompting the user to close the file and each time extending the wait before retrying.
Polly allows chaining of commands, so that we could specify multiple Exception types that the Policy will handle.
Then we call the execute method of the Policy created, passing in our Read File method as a callback function.
When the Policy is executed it catches, like a try catch would, the exception that matches the one specified and retries the callback function up to 3 times before gracefully exiting.
Debugging in Visual Studio
I did come up against an issue when debugging this in Visual Studio. The debugger throws the exceptions as Unhandled by User. This is technically correct as the exception is handled by third party code and not user code, but is confusing and I spent a while wondering why Polly was not handling the error.
Continuing stepping through shows that Polly is handling the exception and retrying.
I found Polly very straight forward to use, and I will be looking at experimenting with some of the other methods available, to see how this would benefit applications I develop.
We have used the Polly library to add fault handling to our simple example, and explored in a basic way how to use some of the features of this library. We have discussed issues that may occur with the Visual Studio debugger.