Different database engines (or dialects) cause different exception types to be raised when attempting to drop a table that does not exist

[Former user]

It would be handy if sqlalchemy raised the same type of exception, no matter what the backend database (as I believe that's one of the main points of sqlalchemy, anyway).

My testing was limited to MySQL and PostgreSQL. Postgres seems to raise a {{{sqlalchemy.exceptions.ProgrammingError}}}, while MySQL seems to go with {{{sqlalchemy.exceptions.OperationalError}}}.

I'm sorry that I'm not posting a test case right now. If you agree that this is indeed a bug, I'll write something up. Please let me know. Thanks. :)

[Mike Bayer]

its a bug, we're supposed to catch those and re-throw

[Former user]

Would you be able to tell me which exception type, specifically, will be thrown ({{{ProgrammingError}}}? {{{OperationalError}}}?).

BTW, I hope you're not confused. It looks like SQLAlchemy actually ''is'' catching those errors and re-throwing them... It's just not re-throwing the same type of exception, for the same class of error, across different backends.

Also, are there any plans to extend the set of exceptions to be more specific? For instance, it'd be ideal for me, in the particular case that I'm dealing with, to be able to catch something like a {{{NonUniqueValueError}}}, as I'm trying to determine if there exists a row that already contains a certain value, for a given ''unique'' field.

I noticed #295, but I'm not sure if that ticket is concerned with the type of error that I'm interested in trapping. (I.e., is it concerned with all errors?)

[jek]

The type would be probably be NoSuchTableError, the same error raised when attempting to reflect a table that does not exist.

[Former user]

Ah, I was confused about which error/exception type I reported this about. The problem described in the original report probably should yield a {{{NoSuchTableError}}}. The problem that I describe in my previous comment seems to yield an {{{IntegrityError}}}, and this seems to be consistent across, at least, MySQL and PostgreSQL.

Oh yeah -- do you need me to write a test case?

[Mike Bayer]

i'm -1 on this since we have the "checkfirst" flag which prevents such exceptions from being raised.

[Michael Trier]

-1 on this as well. Can we close?

[Mike Bayer]

yeah this falls under the category of "normalizing all exceptions" , which is a feature I'd like to see only as some kind of plugin.