ANSI defines the SQLSTATE error codes for portable errors. I think there is SQLSTATE support in most of the databases SQLAlchemy supports (but none in SQLite that I can find), and the error code should be available via db-api either directly (pyscopg2, mysql-python, at minimum) or can parsed out of the text error message.
SQLSTATE is a structured 5 char string that embeds the class of error. You could, say, examine just the first two chars to find out that the error is some kind of constraint violation, or consider the whole code to see that it's a specific duplicate key error. But like everything else sql, database vendors seem to vary in their support. Not all database errors are mapped or even mappable at all to a defined condition in the sql spec. So even the standard SQLSTATE codes don't seem to be useful in practice as much more than a hint, albeit a much better hint than anything else available. That said, I'm +1 on having SQLSTATE and the error message string available as standard attributes on the DBAPIError wrapper. I'm -1 on also providing attribute access to the database's internal error number or code. I don't think I'd be enthusiastic about any proposal to actually modify the type of exception based on the SQLSTATE or error code, at least not until the magic day when all databases raise consistent errors. Until then, shadowing the db-api exception type as we do now feels like the path of least surprise. Michael Bayer wrote: > we do want to get error code availability into our exception classes > (still waiting for any DBAPIs besides psycopg2 to provide these with > no parsing requirement), and there are some cases where we want to > evaulate an exception to discern it from others (such as detecting > database timeouts), but the level of "magic" (i.e., you get some > magic SQLAlchemy error which you cant google for, has less fine- > grained detail than the actual DB error, user database errors now > become SQLAlchemy issues) as well as the huge maintenance problem > this approach would bring (DBAPIs are totally inconsistent, changing > all the time, etc) would be a lot more trouble than its worth, as far > as it being built-in, default behavior. The number of exception > concepts that are truly portable is relatively low (like duplicate > key), so any such functionality I'd say would have to remain as an > electable. > > > On Sep 12, 2007, at 11:30 AM, askel wrote: > >> Hello everybody, >> >> I was wondering why neither DBAPI nor SA define standard exceptions >> like "Duplicate key error". It seems to be no portable way to catch >> this situations and give user more sensible error messages than just >> "We are failed to insert a new record". And using exception >> information to generate error messages make it even more confusing for >> regular (non-Pythonic :) ) people. Since SA dialects deal with >> implementation details wouldn't it be natural to have them translate >> DBAPI exceptions to something more usable as well? >> >> Cheers >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
