Michael, I’m split on this – I think it really depends on the situation. If
these access methods are like low level api to be used in higher end code I
would then throw a custom error and use debug level log only, then in your view
I would catch an error when NoDataReturned and log it as warning.
Perhaps the question to ask is: what data set I want this method to return.
Either homogenous: always a ‘data’ of certain type (with a possibility of an
Exception), or heterogeneous that is either the ‘data’ OR None, if it’s the
latter you are using if/elif blocks if it’s the former you are using
try/except. A homogenous data set is cleaner and easier to debug in my opinion
for such a highly dynamic language as Python. (for opposite see Haskell).
From: Michael Palumbo
Sent: Friday, April 27, 2012 6:17 AM
To: django-users@googlegroups.com
Subject: Re: keep models simple ? where to put the business logic ?
Any suggestions about catching and logging errors right in the models functions
?
Le mardi 24 avril 2012 13:32:27 UTC+2, Michael Palumbo a écrit :
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 ?
I know I have to because when I run the syncdb command, it does not work
unless I specify the app_label meta but I’m really wondering why since I can
still access to them normally like it would be with one file: “from
my_app.models import model1”.
So now I’m convinced that business logic should remain in the models, my
doubts are gone now.
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 and they should thus be on a higher level ?
Should I catch the errors inside my extract function and log them.
Or should I wrap the call of feed.extract() with a try..except block and log
them ?
Maybe it depends on the nature of the errors ?
For example, the download_from_url method will success only if there is data
to return. For example, if the etag is different, it raises a DataNotModified
exception, etc.
For now, I catch it, log it, and return None on my extract method.
def extract(self):
try
data, etag = utils.download_from_url(self.url, self.etag)
#Download from the url
f = self._store(data) #Store it
except (DataNotModified as e):
logger.warning(e)
return none
except (X as e):
logger.error(e)
return none
except (Y as e):
logger.info(e)
return none
self.etag = etag # Change the etag
self.save()
return f
What do you think ?
Thanks
Best,
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-users/-/xIv_DaMs02gJ.
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.
Daniel Sokolowski
Web Engineer
Danols Web Engineering
http://webdesign.danols.com/
--
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.
