Chris Withers wrote:
You're mistaken. The old code did:

def getObject(self, REQUEST=None):
"""Try to return the object for this record"""
obj = self.aq_parent.unrestrictedTraverse(self.getPath())
if not obj:
if REQUEST is None:
obj = self.aq_parent.resolve_url(self.getPath(), REQUEST)
return obj
zLOG.LOG('CatalogBrains', zLOG.INFO, 'getObject raised an error',

Which effectively returns None.

Interesting. Where did that code come from?

It's been there for longer than I've being doing Zope.

All robust old code had to be able to test for None, because it was returned in many cases (when indexes got desynchronised, due to transaction bugs for instance, or manage_beforeDelete swallowing stuff, or conflict errors happening...). I know I had to add lots in my code.

Just because you had to do it in old code doesn't make it not evil. Returning a meaningless value that masks a whole array of possible distinct errors that should all be handled in different ways is mind numbingly stupid IMNSHO. Why you feel so passionately that this should be the case is beyond me. Do you like using bare try: except:s throughout your code too?!

Well of course no, but I never had to check a getObject() against Unauthorized. Maybe it's because I only use it in a CMF setting where unaccessible objects are filtered anyway.

OTOH you're a bit excessive in your "Whole array of possible distinct errors".

Unauthorized in getObject is out of the question, that would be new behaviour.

Well, in 2.8, new behaviour is expected, right?
I really passionately believe that we should not be returnining None in Zope 2.8, and since 2.8 hasn't quite hit beta yet I'm very keen to see it fixed asap.

Any objections?

I'm ok for 2.8. I'll look at it.


Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D
+33 1 40 33 71 59 [EMAIL PROTECTED]
Zope-Dev maillist -
** No cross posts or HTML encoding! **
(Related lists - )

Reply via email to