HackSoftware/Django-Styleguide
1
1
Fork 0
mirror of https://github.com/HackSoftware/Django-Styleguide.git synced 2025-02-16 19:41:00 +03:00
Code Issues Packages Projects Releases Wiki Activity

Add a brief section about more ideas

Browse Source
This commit is contained in:
Radoslav Georgiev 2021-11-22 11:28:57 +02:00
parent 2484bbfc1b
commit 4b993b8b19
No known key found for this signature in database
GPG Key ID: 0B7753A4DFCE646D
1 changed files with 9 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
README.md
View File

@ -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.