mxODBC and exceptions

Paul Boddie paul at boddie.net
Thu Sep 13 10:11:43 EDT 2001


Mikael Lexén <lexen at stop.spam.telia.com> wrote in message news:<3BA060E1.C5D7E407 at stop.spam.telia.com>...
> 
> Thanks for pointing me in the right direction. The exception clause should be
> 
> except mx.ODBC.Windows.IntegrityError:

That looks better, at least.

> Why didn't I get the answer mx.ODBC.Windows.IntegrityError? sys.exc_info()[0]
> gives me the class instance and that name is obviously not the same as the
> exception.

That's probably a question for Marc-André Lemburg, really. I would
expect that the methods which generate the exceptions' visual
representations are still giving names consistent with the old package
structure as opposed to the newer package structure. However, this is
just speculation.

> Are there any function that can give me the real "name" of the exception
> (just curious)?

I don't know, but looking at the DB-API specification [1], I would
think that you would find the exceptions under the module that you are
importing. This made me think somewhat, because to write code portable
across different modules, one would ideally use "neutral" names for
things like exceptions; this would be rather like Java's java.sql
package which provides interfaces that actual implementations support.
(One doesn't need to catch com.sybase.jconnect.SomeException, or
whatever.)

However, I suppose that a similar effect can be achieved by assigning
any given implementation module to a "neutral" variable. For example:

  dbmodule = mx.ODBC.Windows
  connection = dbmodule.connect(...)
  ...
  except dbmodule.IntegrityError, exc:
    ...

Actually, there are a few more things with the DB-API that have come
to light in various forums recently. Perhaps the DB-SIG mailing list
should be reinvigorated...

Paul

[1] http://www.python.org/topics/database/DatabaseAPI-2.0.html



More information about the Python-list mailing list