[Zope] Trying to trap ConflictError

[dieter at handshake.de]

Jonathan wrote at 2006-7-4 09:56 -0400:
> ...
>Traceback (innermost last):
>  Module Zope2.App.startup, line 173, in zpublisher_exception_hook
>  Module ZPublisher.Publish, line 121, in publish
>  Module Zope2.App.startup, line 240, in commit
> ...
>  Module ZODB.Connection, line 554, in _store_objects
>  Module tempstorage.TemporaryStorage, line 200, in store
>ConflictError: database conflict error (oid 0x39b0, class BTrees._OOBTree.OOBucket, serial this txn started with 0x0366974da4fd2288 2006-07-04 13:33:38.669252, serial currently committed 0x0366974da54d9fcc 2006-07-04 13:33:38.742942)
>
>
>in an external method, as follows:
>
>        folder = self.unrestrictedTraverse(TEMPFOLDERIMAGES, None)
>        try:
>                folder.manage_addImage(imageId, imageData)
>        except:
>                <handle error message and return gracefully code>

Such "try: ... except: ..." are *VERY* dangerous.
You can get non deterministic problems with inconsistencies
in your persistant storages -- very difficult to analyse and
to understand.

Never use "try: ... except: ..."!
Put your "graceful code" in "standard_error_message".

> ...
>But the try/except block is not catching the error! (the error continues to show up in error_log)
>(note: I started by trying "except ConflictError:", but that was not working, so I went to the bare try/except)

The traceback tells you that the error does not come from
the "manage_addImage" but from the "commit" at the end
of request processing.

>The traceback does not show where the error originates in the external method

because, it does not originate in the external method...

>  but there is only one place where the external methods writes to TemporaryStorage.

When you change a persistent object, you do not write to the storage
but to a copy of your object in RAM only.

After the request is completely processed, the changes done
during the request are committed (or aborted, in case of an
exception). Only during the commit are your modifications
stored to the storage. In this phase, conflicts are recognized
as well and cause the transaction to be aborted rather than committed.



-- 
Dieter