Actually, Dan and I (we're working together) did some more testing, and our original example now works--without the hub.commit(). We're not certain what we were doing wrong last week, but it seems that, under normal conditions, the rollback error does not happen upon violating an integrity constraint.
I think it's important for me to say that, as of this writing, TurboGears is behaving as we'd hoped : we can treat database integrity violations as exceptions, rather than testing for them beforehand. I regret having stated that this was not the case, but it appeared so at the time. Just a couple of quick responses to Adam's comments: > You said earlier that the exception raised in the first statement was > not making it out of run_with_transaction(). If the exception was > "handled" by raising an error or simply doing nothing, then returning > code execution it would reach the hub.commit(). That manages to raise > the exception for your code to handle it. I believe you're mistaken here. Although TG handled the exception I was attempting to catch, it (actually, SQLObject) raised a new one, which I was not catching. This would preclude execution of my code from continuing. > If you run the code with a global except and reraise the exception it > should give you the exact name you are looking for. Unfortunately, not; the original exception (IntegrityError) is lost by this time. Anyway...thanks, everyone! --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
