On Sep 24, 2007, at 9:36 PM, Ron wrote:
> > In my application I'd like db related errors that are encountered when > using mapped classes to have better exceptions that make more sense in > the context of my program. Where is the best place to put this > stuff? > > For example, say I have a table with a single primary_key column and I > have a class MyData mapped to that table. If someone were to try to > make and flush a MyData(someDuplicateEntry) instance they'd get an > ugly sqlalchemy exception. I'd rather they get, say, an > AlreadyExistsException() or something to that effect. Now, I can wrap > each flush with a try/except block, or have the __init__ method of the > class do a check during instantiation, but I'm wondering if there is > some better way to do it. > > Perhaps a way to map SqlerrorA to throw ExceptionA and SqlerrorB to > throw ExceptionB. > we are doing something like this in order to map DBAPI-agnostic versions of DBAPI exceptions to those thrown by the DBAPI itself, such as a MySQLdb.IntegrityError maps to sqlalchemy.exceptions.IntegrityError. The general strategy is to catch one and then wrap it into the next. we also have some interest in providing SQLSTATE support on our exceptions but that one's still a TODO. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
