I'd prefer to catch some more specific exceptions even though they'd never be generated by most backends rather than decoding SQLSTATE and use if-s or other dispatching method based on what this variable/ exception attribute holds.
On Sep 12, 1:17 pm, jason kirtland <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
