Scott Hanselman

NuGet Package of the Week: Polly wanna fluently express transient exception handling policies in .NET?

January 13, 2015 Comment on this post [13] Posted in NuGet | NuGetPOW
Sponsored By

LOL at my own post title. Pardon me.

Install-Package Polly

Michael Wolfenden has a very clever open source library called Polly. Polly is a .NET 3.5 / 4.0 / 4.5 / PCL library that allows developers to express transient exception handling policies such as Retry, Retry Forever, Wait and Retry or Circuit Breaker in a fluent manner.

Handling exceptions can be a hassle sometimes. Not just setting the try/catches up, but deciding on the policy for the catch can make the exception management code more complex than the method itself!

Polly has a fluent interface to make expressing rules like that much easier. For example:

// Single exception type

// Single exception type with condition
.Handle<SqlException>(ex => ex.Number == 1205)

// Multiple exception types

// Multiple exception types with condition
.Handle<SqlException>(ex => ex.Number == 1205)
.Or<ArgumentException>(ex => x.ParamName == "example")

Then you can add Retry() logic, which is fantastic.

// Retry multiple times, calling an action on each retry 
// with the current exception and retry count
.Retry(3, (exception, retryCount) =>
// do something

Even do retries with multiplicative back off!

// Retry a specified number of times, using a function to 
// calculate the duration to wait between retries based on
// the current retry attempt, calling an action on each retry
// with the current exception, duration and context provided
// to Execute()
retryAttempt => TimeSpan.FromSeconds(Math.Pow(2, retryAttempt)),
(exception, timeSpan, context) => {
// do something

Once you have set up a policy, you execute on it.

.Handle<SqlException>(ex => ex.Number == 1205)
.Or<ArgumentException>(ex => ex.ParamName == "example")
.Execute(() => DoSomething());

Polly also supports the more sophisticated "Circuit Breaker" policy. For more information on the Circuit Breaker pattern see:

Circuit breaker tries and then "Trips the circuit breaker" so you'll get a BrokenCircuitException for some amount of time. This is a great way to give an external system to chill for a minute if it's down. It also externalizes the concept so that you could theoretically handle a down database the same as you handle a down external web API.

// Break the circuit after the specified number of exceptions
// and keep circuit broken for the specified duration
.CircuitBreaker(2, TimeSpan.FromMinutes(1))

You can explore the code, of course, up on Github in the Polly repository. Go give the Polly project a star. They've recently added async support for .NET 4.5 as well!

Sponsor: Welcome this week's feed sponsor, Stackify! - The only developer-friendly solution that fully integrates .NET error & log management with application monitoring. Easily isolate issues and focus your efforts – Support less, Code more. Free trial

About Scott

Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.

facebook twitter subscribe
About   Newsletter
Hosting By
Hosted in an Azure App Service
January 13, 2015 6:01
Timely blog post for my usage, thank you. Here is circuit breaker pattern details from MSDN
January 13, 2015 12:27
I have used Polly for a long time. Blogged about the great little framework in 2013: Automatic Retry and Circuit Breaker made easy
January 13, 2015 14:51
This is a life saver!!! Never heard of it, but always need it. I always need to do it by hand.

Anders, I need to follow you!

If I know this back in 2013...
January 13, 2015 22:11
I must admit I've never heard about Polly before. Interesting library! It looks promising for retrying actions with exponentially growing pauses in between.
January 14, 2015 2:01
Reminds me of
January 14, 2015 13:28
We have been using Polly for a bit. Good library, but I would like to see a Handles overload that takes a predicate that looks at the return value of the method being called. I quickly found myself wrapping methods to throw exceptions based on return values that indicated a failure simply so I could use Polly to apply a policy. The answer? Me (or someone) submitting a pull request with this feature!
January 14, 2015 19:27
Looks promising but beware of disposable objects and using statements
January 14, 2015 21:52
People interested in this and writing systems on Azure should also be aware of these things that are designed specifically for Azure:

The Transient Fault Handling Application Block

Which, I'm not sure, may have been superceded by progress in this area:

Storage Client Library

And for those using a recent EF version with SQL Azure DB, look no further than this:

"When you use the Entity Framework you typically aren’t working directly with SQL connections, so you can’t use this Patterns and Practices package, but Entity Framework 6 builds this kind of retry logic right into the framework."
January 19, 2015 2:12
Heres Polly applied to EF6 connection resiliency...

<a href="""">Entity Framework Connection Resiliency and Polly</a>

January 21, 2015 4:40
It works beautifully in F# too.
January 22, 2015 12:31
So glad to see Polly getting some more recognition. Came across it last year, contributed the PCL implementation because it is just an absolute killer nuget package for both both client AND server side. On client side use the RetryPolicies and server side use Circuit Breaker to prevent thundering heards. By client I mean in mobile applications w/Xamarin :-)
January 22, 2015 12:37
For EF6+ & Azure when transient errors handling is batteries included, just plug them in:

SetExecutionStrategy("System.Data.SqlClient", () => new SqlAzureExecutionStrategy(1, TimeSpan.FromSeconds(30)));

Which will retry instantly the first time a transient failure occurs, but will delay longer between each retry until either the max retry limit is exceeded or the total time hits the max delay. The execution strategies will only retry a limited number of exceptions that are usually transient, you will still need to handle other errors as well as catching the RetryLimitExceeded exception for the case where an error is not transient or takes too long to resolve itself.
February 18, 2015 12:49
great points altogether, you just gained a new reader. What could you recommend about your
publish that you just made some days in the past? Any positive?

Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.