Exception Handling & Logging
This article aims to standardize the entire logging process and improve the handling of exceptions.
- Exception handling should be in Service or Container classes.
- Repository classes should throw exceptions to Service or Container classes.
- You should use Polly in your project and set retry and circuit-breaker policies to avoid instant errors (ex. sql connection errors, http dns errors etc..)
- For all logs you should use our app ( TODO : nuget link )
- Covering all code
try { ... } catch (Exception e) { }
DOESN'T mean that this code is handled. (It's a good read if you want to know the difference between checked and unchecked exceptions.) - Logging types :
- Fatal : ( it should be reviewed/responed by one of backend guy and posted to slack channel )
- All exceptions
- If it is http request and response code is 50X
- If the issue persists after Polly n attempts
- Warn :
- Each Polly retires
- If game url isn't generated because of wrong game id.
- Affordability not found errors
- Info :
- Each custom logs.
- Fatal : ( it should be reviewed/responed by one of backend guy and posted to slack channel )
- Each requests should have unique guid and be passed it to every internal services in header with
X-WALogTrace-Id
parameter. - Each applications should have unique names.