[Zope3-dev] Re: [Zope-dev] Re: tal:on-error is a bare except...

[Tim Peters]

[Tres Seaver]
> I don't believe the bare except is *ever* good form in
> production-quality code.

Me neither.

> *No* application-level code has enough zen to swallow some kinds
> of exceptions, which is why the Java folks have a
> separate RuntimeError hierarchy.

I think that's really because Java requires declaring which
non-RuntimeError exceptions *may* be raised, and despite Java's love
of verbosity even they couldn't abide having to declare every
exception deriving from RuntimeError on every method.

> The fact that newer ZODB's *appear* to prevent later commits does not
> exculpate the use of the bare except in 'tal:on-error' (emphasis added
> to indicate a non-trivial amount of suspicion against the code paths in
> question;  we have claimed to have solved that problem before).

Floerent mentioned ZODB 3.3, but I think that's a red herring.  It's
already in ZODB 3.2:  check your testZODB.py for the existence of this
test:

    def checkReadConflictIgnored(self):
        # Test that an application that catches a read conflict and
        # continues can not commit the transaction later.

If that's there, it's testing for what the comment says it's testing
for.  However, this is subtler than a quick reading of the comment may
suggest.  A fuller account is here:

    http://mail.zope.org/pipermail/zodb-dev/2004-May/007404.html

Short course:  if you suppress a ReadConflictError, a later attempt to
commit will raise ConflictError.  *But*, once ConflictError is raised
during commit, that transaction is history, and a new transaction
(implicitly) begins.  So if you swallow the later ConflictError too,
you're suddenly in a new transaction, with no warning (well, it
*tried* to warn you, by raising ConflictError, but you wouldn't
listen).

That said, I still hear persistent rumors that catching
ReadConflictError can still do real harm, even if you don't suppress a
subsequent commit() excpetion.  I would love to see a specific
instance of such harm with a current ZODB 3.2.  I'm not an expert in
this code, there may be bugs in it still, and it's not clear that the
scenario set up by checkReadConflictIgnored is the only scenario
that's possible.