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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment