On Apr 24, 1:32 pm, Michael Palumbo <michael.palumb...@gmail.com> wrote: > Hi guys, > > Thanks for your answers, it helps. > > - Anemic domain model : I didn’t know about this before, it is good to know. > - Daniel : if I split my models and import all of them in my __ini__.py > file, why do I still need to use the app_label meta ?
1/ tables prefix 2/ all management commands working on apps > However, my feeling of having a complex models might also come from the > fact that I put some numerous try..except blocks inside my function and log > the errors. > So my question is: when raising and catching errors and when logging ? > We could say that catching errors and logging are not part of the business > logic either Why so ? > and they should thus be on a higher level ? Depends... As a general rule, only catch exceptions you can handle, else let them propagate. There are a few cases where you want to catch some exception you cannot directly handle: 1/ when you want to log some contextual info before re-resaising the original exception 2/ when you want replace the original exception by your own to "hide" some low-level implementation detail and/or help the calling code handling this particular error. In both cases, don't assume to much about what really happened in the first place and keep as much debugging info as possible. Also, remember that django already comes with a top-level exception handler around your views, so the worst thing that may happen is an HTTP 500. -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
