Florent Guillaume wrote:
Is everyone ok with returning
- the object if it can be accessed
- raise Unauthorized if it can't be accessed
- raise NotFound if it's not there
Please don't catch any exceptions and re-raise them in a different type,
just let them pass through.
I specifically don't
Florent Guillaume wrote:
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.
Maybe, but CMF isn't the only use of Zope ;-)
OTOH you're a bit excessive in your Whole
Florent Guillaume [EMAIL PROTECTED] wrote:
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
Florent Guillaume wrote at 2005-4-1 13:21 +0200:
Florent Guillaume [EMAIL PROTECTED] wrote:
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
On Thu, 2005-03-31 at 13:02 +0100, Chris Withers wrote:
Would anyone object if I wrote tests and changed the implementation to
raise exceptions, including Unauthorized, instead of returning None?
Unauthorized in getObject is out of the question, that would be new
behaviour.
Well,
Chris Withers wrote:
You're mistaken. The old code did:
def getObject(self, REQUEST=None):
Try to return the object for this record
try:
obj = self.aq_parent.unrestrictedTraverse(self.getPath())
if not obj:
if REQUEST is None:
Florent Guillaume wrote:
2. is necessary for backward compatibility. *all* the previous
implementations of getObject returned None in case of problems.
This is the only bit I'm asking about, I accept that I'm in the insane
minority on the other point ;-)
Just because that's what it did before
Chris Withers wrote:
Just because that's what it did before doesn't mean we should leave it
like that. I can see absolutely no benefit in returning None over
raising a specific error.
Also, the original behaviour of getObject, prior to Casey's drastic and
unexpected switch to
