Edition 0 Updated to asp. Net core 0

public
class
CartController : Controller 
{ 
//…
public
async Task 
Index
() 
{ 
try
{ 
var
user = _appUserParser.
Parse
(HttpContext.
User
); 
//Http requests using the Typed Client (Service Agent)
var
vm = await _basketSvc.
GetBasket
(user); 
return
View
(vm); 
} 
catch
(BrokenCircuitException) 
{ 
// Catches error when Basket.api is in circuit-opened mode
HandleBrokenCircuitException
(); 
} 
return
View
(); 
} 
private
void
HandleBrokenCircuitException
() 
{ 
TempData[
"BasketInoperativeMsg"
] = 
"Basket Service is inoperative, please try later 
on. (Business message due to Circuit-Breaker)"
; 
} 
} 
Here’s a summary. The Retry policy tries several times to make the HTTP request and gets HTTP errors. 
When the number of retries reaches the maximum number set for the Circuit Breaker policy (in this 
case, 5), the application throws a BrokenCircuitException. The result is a friendly message, as shown in 
Figure 8-6. 

---

311 
CHAPTER 7 | Implement resilient applications 
Figure 8-6. Circuit breaker returning an error to the UI 
You can implement different logic for when to open/break the circuit. Or you can try an HTTP request 
against a different back-
end microservice if there’s a fallback datacenter or redundant back
-end 
system. 
Finally, another possibility for the 
CircuitBreakerPolicy
is to use 
Isolate
(which forces open and 
holds open the circuit) and 
Reset
(which closes it again). These could be used to build a utility HTTP 
endpoint that invokes Isolate and Reset directly on the policy. Such an HTTP endpoint could also be 
used, suitably secured, in production for temporarily isolating a downstream system, such as when 
you want to upgrade it. Or it could trip the circuit manually to protect a downstream system you 
suspect to be faulting.