An error in the business logic is not a data inconsistency - assume for this example that 0 is a fine and correct value for a non integer entry. I am just worried about stuff that Zope does on the back end, for example raising ConflictErrors, etc. - Dieter seemed to indicate that any use of try and except could cause such problems. I thought that as long as I don't have any naked except statements that will accidentally catch ConflictErrors, that I only have to worry about what I see in my code, but when I said that, Dieter seemed to indicate that I was wrong - however, his latest response would seem to indicate that I was right. So now I am confused.
-----Original Message----- From: Andrew Langmead [mailto:alangmead@boston.com] Sent: Thursday, October 21, 2004 12:07 PM To: Sean Hastings Cc: zope list Subject: Re: [Zope] adding properties trough pythonscript
On Oct 21, 2004, at 11:18 AM, Sean Hastings wrote:
def fooEdit(self,REQUEST): "foo is a string - foo2 is an int" self.foo = REQUEST.get('foo','') try: self.foo2 = int(REQUEST.get('foo2',0) except ValueError, e: self.foo2 = 0
Then could I say that this would be an example in which catching SOME exception CAN NOT result in inconsistent data?
Depends on the connection between "foo" and "foo2". Maybe 0 is a good default for foo2 if it is not present, but the client wouldn't want it reset to 0 if it was supplied and incorrect.
For example imagine the input coming from an HTML form snippet like this. The option for "Shoes" has a small typo.
Item: <select name="foo2"> <option value="0">Skirt</option> <option value="1">Jeans</option> <option value="2">Overcoat</option> <option value="e3">Shoes</option> </select> Color: <input type="text" name="foo" size="40" />
You wouldn't want the shoes converted to a skirt just because of a typo in the form.
def fooEdit(self,REQUEST): "foo is a string - foo2 is an int" try: newfoo = REQUEST.get('foo','') newfoo2 = int(REQUEST.get('foo2',0) except ValueError, e: raise InvalidInput(e) else: self.foo = newfoo self.foo2 = newfoo2
and have something at a higher level catch InvalidInput and report it to the user. Or maybe in this case, you might be able to report the error within .fooEdit because the changes to the ZODB are moved after the rest of the processing. But that is someone depending on implicit knowledge that .get() and int() won't change the persistent state.