As much as I try to avoid them (especially in Zope code), they are sometimes 
necessary because you simply don't know what exceptions might be raised from 
inside Python or the standard libs. Besides, even if you stamped it out 
people will just use:

except Exception:

Besides, sometimes you really do want to trap all exceptions, do something and 
then re-raise them again. IMO that's not bad form if its not habitual.

Even simple operations in Python itself can raise various exceptions. For 
instance, a humble int(x) can raise TypeError or ValueError, and Guido knows 
what else ;^). That leads to me being less confident in my exception handling 
then I would like to be.

At any rate Chris McDonough and I recently had a conversation about ZPT 
catching all exceptions and his sneeking suspicion that it was a bad thing 
with regard to read conflicts, but I think we concluded it wasn't as bad as 
he thought it might be. Maybe we were wrong.

Since you have identified these places in the code, I think it would be 
worthwhile to add the following above the bare excepts in question to see 
what happens:

except ReadConflictError:

If nothing else, you could rule this out.


On Thursday 03 October 2002 08:58 pm, Guido van Rossum wrote:
> > PS: Hey, Guido, any chance of deprecating exceptionless 'exception:'
> > clauses anytime soon? We got a bunch of those making our life harder
> > on Zope :-)
> No chance for backwards compatibility, but I try to stamp them out
> whenever I see them.  Submit a tracker issue about the ones that
> particularly bug you -- with patch if you've got a suggestion.
> We'll get there still.
> --Guido van Rossum (home page:
> _______________________________________________
> Zope-Dev maillist  -  [EMAIL PROTECTED]
> **  No cross posts or HTML encoding!  **
> (Related lists - 
> )

Zope-Dev maillist  -  [EMAIL PROTECTED]
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to