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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
