From 4b993b8b19d352a7083efce2d6ed63b2fe742b7d Mon Sep 17 00:00:00 2001 From: Radoslav Georgiev Date: Mon, 22 Nov 2021 11:28:57 +0200 Subject: [PATCH] Add a brief section about more ideas --- README.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/README.md b/README.md index 7835720..bb11792 100644 --- a/README.md +++ b/README.md @@ -45,6 +45,7 @@ Django styleguide that we use in [HackSoft](https://hacksoft.io). * [Know how to change the default exception handling behavior.](#know-how-to-change-the-default-exception-handling-behavior) * [Approach 1 - Use DRF's default exceptions, with very little modifications.](#approach-1---use-drfs-default-exceptions-with-very-little-modifications) * [Approach 2 - HackSoft's proposed way](#approach-2---hacksofts-proposed-way) + * [More ideas](#more-ideas) - [Testing](#testing-2) * [Naming conventions](#naming-conventions) - [Celery](#celery) @@ -1819,6 +1820,14 @@ Now, this can be extended & made to better suit your needs: **The general idea is - figure out what kind of error handling you need and then implement it accordingly.** +### More ideas + +As you can see, we can mold exception handling to our needs. + +You can start handling more stuff - for example - translating `django.core.exceptions.ObjectDoesNotExist` to `rest_framework.exceptions.NotFound`. + +You can even handle all exceptions, but then, you should be sure those exceptions are being logged properly, otherwise you might silence something that's important. + ## Testing In our Django projects, we split our tests depending on the type of code they represent.