[Zope] adding properties trough pythonscript

[Andrew Langmead]

On Oct 18, 2004, at 1:36 PM, Dieter Maurer wrote:

> Sean Hastings wrote at 2004-10-18 01:58 -0400:
>> I believe that "try: ... except:..." code is only really dangerous if 
>> you do
>> not specify the type of Exceptions that will be caught.
>
> I believe you are wrong:
>
>   Catching *ANY* exception can cause inconsistencies in persistent 
> data.
>
>   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).



I have a large body of code written in the manner that Sean is 
describing, and after some time maintaining it, I'm now starting to 
lean towards what Dieter is saying.

I have a system with an automated data import subsystem (for import of 
"wire feeds" and such) , an event channel alerting various subsystems 
about new changes throughout the system, and a web page creation 
subsystem that create special styles of pages and layout based on any 
criteria that it can query from the surrounding environment (for 
example, if it is creating a new page based on a politics story, it can 
add a related items link list, etc.)

I've seen a few cases where the following happens,
* A new story comes into the system from the feeds subsystem.

* The feeds subsystem sends a "new content" message the event channel.

* The event channel invokes  page creation subsystem creates a new 
page. (doing a little "self._setObject( id, page );page = self._getOb( 
id )" dance to get a wrapped object instance and at that point altering 
the persistent state)

* The page creation system then starts adding items to the page. One of 
them throws an exception, that is caught in the event channel that 
invoked it.

The end result is a page that is missing some of its critical 
components.


I'm starting to think that in this case, the code that handles the 
event channel should be less specific, rather than more explicit about 
the exceptions it should catch, along with a subtransaction abort and 
commit for each message handler it invokes. ( I definitely don't think 
the exception should bubble up any higher and abort the feeds import, 
because the other content coming through the feeds may be more 
important than this one story. Maybe lower into the page creation into 
the page creation subsystem might give more control over the error 
handling.)

It definitely doesn't help that Python's dynamic nature here makes it 
very hard to predict which errors might be occurring. (for example, I 
noticed that the date parsing code for the DateTime object in 2.8a now 
gives a consistent exception for syntactically invalid input. Up to 
now, you could get some odd mix of DateTime.DateTime.DateError, 
DateTime.DateTime.TimeError, IndexError, KeyError, TypeError, or 
whatever else may be wrong with the input. Specific try:except:s are 
hard to develop when you have no specific enumeration of the errors 
that might be emitted for any particular method. (Don't get my wrong 
and take that as a condemnation of the python language as a whole. Its 
just one of those things where the more possibilities that you have 
before you, the more ways you can fail.)