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: try: ... 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: raise If nothing else, you could rule this out. -Casey 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: http://www.python.org/~guido/)
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )