feature request- extend core DBAPIError exceptions with connection/engine information if available

[jvanasco]

in a trivial example, given a session with a database that does not contain foo...

try:
    sess.execute("SELECT foo;")
except Exception as e:
    print "Exception!", e
    pdb.set_trace()

e will be a sqlalchemy.exc.ProgrammingError (under Postgres and others, which inherits from DBAPIError).

The current design of DBAPIError makes it hard to tell what connection caused the error -- which is important in multi-connection environments (and probably connection pools).

The may be raw connection info via the underlying connections's cursor (e.orig.cursor.connection works for postgres via pyscopg2), but this request is to make information about the SqlAlchemy Connection object on the DBAPIError .

[Mike Bayer]

we can't do that because exception objects hang around outside of blocks, functions, and other things that really want to close out resources and get rid of things - there are also some nasty circular reference issues with exceptions that would likely get triggered by holding all of that onto the exception (i'd have to dig to look up what it was).

However, you can have everything you want right now! use the handle_error event which will give you everything you could dream of about the exception and more (plus you can tack the Connection and all of that onto it also even though I don't recommend it). this event is used very elaborately within Openstack (and is also how I learned about the cycle issue).

[jvanasco]

well then, rescinded!

thanks for the explanation and suggestion.

i was able to pull everything I needed off the psycopg cursor, if i ever need this on another platform I can use the handle_error event. this seemed like the sort of information that would be useful to others though, so I opened a ticket.