When you define a Polly exception-handling policy, the policy will internally catch matched exceptions and handle them as the policy defines: orchestrate a retry; update circuit-breaker statistics; or channel execution to a fallback.
Debugging such executions can however be noisy in Visual Studio: commonly-used settings cause Visual Studio to
Polly offers both non-generic policies Policy with a generic .Execute<TResult>(...) method, as well as generic policies Policy<TResult>. This article sets out to answer questions Polly users sometimes raise: Why do both exist? And why can't I just use the generic .Execute<TResult&
TL;DR In Polly V5.1.0, we've extended Context so that it can be used to pass information between different parts of an execution through a policy. Featured Use Cases include honouring RetryAfter headers, and re-establishing authentication automatically.
Context?Web request frameworks in .NET such as ASP.NET
A few days ago I sat down (virtually) with Bryan Hogan of the NoDogmaPodcast to record a podcast on an Introduction to Polly.
In the podcast we talk about common resilience patterns, why you need them, and how you might use them - starting with well-known patterns such as Retry
Today we released Polly v5.0 in alpha to Nuget. This is the next step in making Polly a much wider resilience framework for .NET, as Hystrix is for Java.
TL;DR, the new resilience policies and features are: