In the previous articles in this series, we have seen how to author custom reactive and proactive Polly policies:
In this article we'll build our first reactive custom Polly policy: a policy to log exceptions or fault-results.
Polly polices fall into two categories: reactive (which react to configured faults) and non-reactive / proactive (which act on all executions). To author a proactive policy, see Part II: Authoring a proactive custom
In this article we'll build our first custom Polly policy: a proactive Policy to capture execution timings.
Polly polices fall into two categories: reactive (which react to faults) and non-reactive or proactive (which act on all executions). To author a policy which reacts to faults, see Part III: Authoring a
The Polly team have long wanted to allow users to extend Polly's capability with custom policies.
Polly v7.0 introduces a simple mechanism for authoring custom policies which integrate fully with the existing Polly architecture: the fault-handling syntax, the execution overloads, and the ability to combine policies
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
