Skip to main content

Exception Handling & Logging

This article aims to standardize the entire logging process and improve the handling of exceptions.

  1. Exception handling should be in Service or Container classes.
  2. Repository classes should throw exceptions to Service or Container classes.
  3. 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..)
  4. For all logs you should use our app ( TODO : nuget link )
  5. 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.)
  6. Logging types :
    1. 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
    2. Warn :
      • Each Polly retires
      • If game url isn't generated because of wrong game id.
      • Affordability not found errors
    3. Info :
      • Each custom logs.
  7. Each requests should have unique guid and be passed it to every internal services in header with X-WALogTrace-Id parameter.
  8. Each applications should have unique names.