Exception Handling

Reminder

• prefer the name Exception instead of Error, Exception is bounded in the exceptions raised by python code, Error can mean human errors and have much larger implication, makes it harder to think.
• assume each third party integration failed
• it’s a business / BA decision when there is no perfect solution
  • confirmed with BA, on what should the error message be?
• use with transcation.atomic()
  • put a single DB update/save with Curo call using submit_entity_unhandled
  • don’t use decorator @transaction.atomic to avoid future changes that introduces errors in error handling logics
• validate first, client facing logics last (e.g. sending emails)
• in Submission, avoid duplicate oneview and curo entities by using get_or_create?
• submission code / function must be idempotent to allow safe user retry or even auto retry

Principles

• Exception Handling means what are the correct business logics when errors happen
• consider curo as extension of oneview DB, so wrap curo call and DB changes in one transaction
• in general, one cannot revert a third party API call, because of possible side effects of the API call

Example: Curo

with transaction.atomic():
    task = Task.objects.create(...) # or update some properties then task.save()
    submit_entity_unhandled()

Example: Third Party API Call

# if response data is needed
foo_id = third party POST or PATCH
raise_for_status()
save `foo_id` to local DB

• if third party call failed, not bad state, because there will be no local db changes.
• if save to local DB failed, bad state happened, maybe the solution is to verify first to avoid saving to local DB failed? because of the stable network or retry mechanism, unless this is DB constraint, save to local DB shouldn’t failed, so maybe verify can avoid the failure to local DB.