> Most likely, yes. And those people, believe it or not, designed > Django's APIs based on their experiences. This is why there are > shortcuts available, like the get_or_create() method (which fetches an > object or, if none matches, creates a valid one, populated with > default values you supply, for you), and why these sorts of methods > are covered in Django's documentation.
I want a NullObject - not "create", which (correctly) implies a save() > In general, though, it appears you're trying to apply an anti-pattern: > silencing an exception which told you that something went wrong, and > then passing a "null" object into other code to try to compensate. > This is an approach more likely to create bugs than to solve them, and > so if implementing it is a bit harder than you'd like, perhaps that's > why. And again the condescension. As a programmer, I should be able to easily chose between statements that throw and ones that efficiently deal with branching conditions. A record-not-found is not a crisis, it is just a branching condition. 5 excess lines of code do not make my program more robust. Oh, look! "123"[:7] ! The string doesn't have 7 characters! Gee, shouldn't that throw an exception? -- Phlip -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@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.
