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.)