Clemens Robbenhaar wrote:
I remeber I made a collector issue about that liens of code:
Indeed. Catching everything and raising a string exception is evil, and I was glad to see that go.
Previously this has been a string valued exception. Actually I like it
to be an exception of a certain type now, because I can now selectively
catching this DatabaseError and distinguish it from other errors. No
need for a evil bare except.
Well, I'm afraid I don't agree here...
The reason is that I would like to treat errors when accessing an external data base different from other errors; often the data obtained there is only "optional" to the page, so I don't want to show usered the error page in this case, only to fill up doem slot with "sorry, that certain piece of information is not availabe, because our sql data base sucks".
...this is an application level decision. The code currently makes it very easy, but at the expense of debugging any unexpected exceptions that code throws. While relational data may be "optional" for you, for many people it is ESSENTIAL, and is used for things like their auth details, content storage, etc.
For them, this piece of code causes MAJOR suffering, especially for intermittent failures where you can't just insert a print_traceback and try again ;-)
I see Your point. However is there any chance that "dbc()" does raise something more specific? I am afraid it does not.
No, that's the whole point. If that code raises an exception, it's much more useful if it can be logged and dealt with in its original form rather than have it morphed into something uniform and meaningless.
If it does not, I would have to go back to an evil bare except ...
I wouldn't if I were you:
*your zsql method
return "sorry, that certain piece of information is not availabe, because our sql data base sucks"
If your database adapter raises a string exception, THEN you have to add a bare except on the end of that, but if that's the case you should beat the DA author with a stick until he fixes it.
-- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce