SQLAlchemy doesnt throw MySQL exceptions directly because that would prevent applications from being written which are portable to different databases. This because youd otherwise have to say, try/ except (MySQLDB.OperationalError, psycopg2.OperationalError, pysqlite2.OperationalError), etc.
So it wraps them in SQLError, which a database-neutral application can catch and from which you can extract the MySQL exception. However, we also will soon be breaking out the individual DBAPI errors, such as OperationalError, ProgrammingError, IntegrityError, etc. into individual SQLAlchemy exceptions so that you can catch them individually. They still will "wrap" the actual exception thrown by the DBAPI, but i think what you're looking for is just differentiation among the basic types. Look for this new feature in SA 0.4, if not in the first release it'll be soon after that. Also, feel free to post SQLAlchemy questions on the SQLAlchemy list where they'll be answered a lot quicker in most cases. On Aug 7, 2:53 am, SamDonaldson <[EMAIL PROTECTED]> wrote: > Hi, > > I've been quite frustrated with how Mysql DB exceptions get caught if > I'm going through sqlalchemy to run my DML. I really don't want to > have to catch sqlalchemy exceptions. For example, I'd like to be able > to catch the Mysql IntegrityError. How can I work with MySQL > exceptions vs sqlalchemy ones? > > Thanks, > > SAm. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
