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
Azure Cognitive Services is an excellent series of cloud-based APIs that open up a world of artificial intelligence (AI) opportunities that you can easily add to your applications and data process flow. Each service contains a set of trained and field-tested machine learning models that are continuously retrained for greater
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&
