Service fabric Unprocessed exceptions and best practices

Just curious if anyone has experience with unhandled exceptions in Service Fabric and what are their best practices. Mostly curious about the faulty status of services. Are services provided again if they are out of order? Or there should be global exception handling for unhandled exceptions, if this concept exists even in SF. I did not find much in this thread while doing a search.

+10
source share
2 answers

At my company, we created the code for reuse, following the recommendations for using ITransaction , which allows us to run any arbitrary code and include it in the appropriate rules for handling exceptions and retries. This documentation provides guidance on how different types of exceptions should affect the RunAsync method, and how they should affect methods that are part of the remote endpoint.

Generally, handling any exceptions beyond what is discussed in the documentation is up to you. For me, I’ll just let an exception pop up and let the service fail if it is an unexpected exception. Expected exceptions should always be handled with an appropriate retry policy.

0
source

Your question is quite broad, and the answer varies depending on the type of microservice. Once a good time to start, and to get an idea of ​​the enormity of this subject, is to look at the Fabric Health Monitoring Service and related subtopics. As you can see, there are many configuration options, and in my experience (I am the architect of Microsoft Azure) there is no silver bullet, there is no "one size fits all" solution. The only best practice is to design an exception management that is best suited to your project, making the most of Fabric health policies.

-1
source

All Articles