Chris Withers writes:
Clemens Robbenhaar wrote:
Hm, figuring out the "right" exception actually the problem; if the data base connector would raise an exception of a certain type due to unability to connect I could catch these and let the others pass.
Which DA are you using? It _should_ do that...
ZMySQLDA -> raises MySQLError and OperationalError from module MySQLdb (so far I have seen those at least ;-)
Unfortunately I am not able to figure out the interesting ones so quickly by experimenting, because I cannot think about (or even reproduce) everything that may actually fail.
The specifc DA you are using should subclass all it's exceptions from a base exception. ZOracleDA does this the right wya, fro mwhat I've seen...
But it is a base exception class in ZOracleDA, however. Thus the product using it need to explicitely import this exception, and thus explicitely depend on the used relational database; code needs to be rewritten if one exchanges the external data base. (Well, if one uses something ambitious like oracle, sure there are more implicit dependencies in the used sql statements so one cannot simply switch to something e;lse anyway ;-)
Maybe the "DatabaseError" class could remain in the DA.py, so specific data base connections could reuse this exception type?
Sounds like a plan, now you jus thave to persuade the DA authors to start using it ;-)
Well, um, yes, at least I am asking if it makes sense to keep the exception DA.DatabaseError in the code, even it it is not yet / no longer used. I see DA-maintainers are not all rushing out for using it, however ...
product to use this exception now? (btw: does somebody know, if Zope3 would maybe have such an "external data source connection" specific exception?)
Ask on zope3-dev@zope.org...
Well, I guess I should first read the Zope3 wiki ;-) Cheers, Clemens