[Zope] adding properties trough pythonscript

[Dieter Maurer]

Sean Hastings wrote at 2004-10-19 14:20 -0400:
>It may be that I do not understand some voodoo going on in Zope control
>flow - by what mechanism would either of the code examples below end up with
>foo and foo2 in a state inconsistent from the values passed in the last
>transaction to finish?
>
>
>>   Catching *ANY* exception can cause inconsistencies in persistent data.

The "any" refers to "any type of exception" (i.e. not only
"ConflictError"). It does (of course) not mean that any exception
catching does (with necessity) result in inconsistent persistent data.
That's why there is a "can" in the sentence above...

>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
>
>
>>   It does (almost surely) when the "try" block modified persistent
>>   state before the exception occurred (and you did not ensure that
>>   the transaction is aborted).

Please reread paragraph above (which you quoted from my previous message).
*carefully*.

In your example, the exception occurred *before* you modified
persistent state....

Let's extend your example a bit:

      try:
		foo2 = REQUEST.get('foo2',0)
		self.foo2_str= foo2
		self.foo2 = int(foo2)
      except ValueError:
	        ...

And unless you do special things, "foo2_str" and "foo2" are no longer
consistent...

> ...
>I am sure that you know more about both Python and Zope than I do, but I
>really don't want to believe that the design of Zope prohibits the use of
>such a fundamental part of the python language as raising and catching
>exceptions.

Catching exceptions is dangerous all over Python!
That's why Python provides the "try: ... finally:...".
It allows you to clean up inconsistencies caused by exceptions -- if
you care about them.

In a normal Python process, data's life is limited -- all objects die
when the process stops.
Zope makes the danger far greater -- because it introduces persistent
state -- objects that live (in principle) forever. Inconsitencies
become by that far more serious.

This is in fact not special to Zope but to any system with persistent data.
E.g. if you catch exceptions carelessly (and later commit) in
an application having persistent data in a relational database,
you run the same risk...

-- 
Dieter