On Thursday 01 June 2006 05:30, Jorge Vargas wrote:
> > The biggest problem is to translate exceptions. One DB API driver
> > raises
> > OperationError when another raises IntegrityError. We need to collect
> > information about what exceptions every driver raise in what
> > situations.
>
> I don't like that even if all the trace info is preserved the exception
> name (which something is all you need to figure out the error) is lost.
If you check the sample code I offered it's easy to preserve the exception
name in the generic exception. It will give something like:
DatabaseError: _mysql_exceptions.OperationalError: (1045, "Access ...
which can pretty easily identify the problem even without a backtrace.
The only purpose of the generic exception here is to present all backend
exceptions under a common name so I can catch a database problem easily
like this:
try:
code
except DatabaseError, why:
do something
instead of this:
try:
code
except (_sqlite.DatabaseError, MyQSLdb.Error, ... endless list of backend
exceptions I don't really want to know about ...):
do something
the later is complicated to do even if I'm considering it, as I don't have
all the backend modules on my system to load and I need to create dummy
exceptions for them so it works on systems where people use other
backends than me.
There is a third alternative, but that is not elegant either (at least
this doesn't require me to create dummy exceptions for the db modules I
don't have around):
try:
code
except Exception, why:
info = sys.exc_info()
try:
module = info[0].__module__
exception = info[0].__name__
finally:
del info
if module in ('_sqlite', '_mysql_exceptions', ...):
do something about the error
else:
raise
--
Dan
-------------------------------------------------------
All the advantages of Linux Managed Hosting--Without the Cost and Risk!
Fully trained technicians. The highest number of Red Hat certifications in
the hosting industry. Fanatical Support. Click to learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
_______________________________________________
sqlobject-discuss mailing list
sqlobject-discuss@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
