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 [EMAIL PROTECTED]
Well, I guess I should first read the Zope3 wiki ;-)
Zope-Dev maillist - [EMAIL PROTECTED]
** No cross posts or HTML encoding! **
(Related lists -