Exceptions are one of the least considered item when it comes to architecture and developing application . Conversations about exceptions always goes as follows
If there is a exception , We will Log it and show an error page to user — Yoda from Star Trek
In software systems, exceptions will occur. Even with perfect, bug-free code, problems will arise when we have to deal with the issue of connectivity. If a database is overloaded, or a web service is down, we have no recourse except to try again.
Here are some of ways to differentiate the exception and this will help you build a resilient systems
Transient :
Transient errors are something if immediately retried, would likely succeed.
Lets consider a scenario if the databases server suddenly had a deadlock with another process . Then a retry in 5 seconds or less then the deadlock will be removed.
Semi transient :
This is similar to the above exception but will not succeed immediately , Like a external web service failure and it may take some time to come back .
So a Circuit breaker pattern works great in this scenario .
Systematic Exception
Outright flaws in the system can cause failure , Famous Null reference exception , Argument Error and host of other common mistakes can cause the error .
In short these exceptions may need some kind of Bug-Triage -Fix cycle to solve the same .
Understanding these different types of exceptions and how to handle them will make the system design really resilient to work with and also makes the application easy to maintain .
There are so many patterns to build application which can handle these error scenarios in a graceful way and help business move forward .
I have found the .net Library called Polly to handle the similar scenario in a graceful way . I suggest you check this up
More about making the application resilient in next blog post to come.
