consistent error code handling

[Mike Bayer]

we had someone wanting postgres SQLSTATE values to be propagated. i could not find any psycopg documentation at all about this being available, but then someone just posted an example that illustrated the undocumented psycopg attribute that makes this available.

the SQLError exception should have a "code" attribute that tries to get at the SQLSTATE/error number reported by the database, if possible. and maybe also "message". this way people wont need to drill into the db-specific exception itself. will need to build hooks into the dialect to populate this value when sql exceptions are raised.

the hard part here is identifying how all the dbapis report the code/message...im a little skeptical if they even all have codes.

[Mike Bayer]

this ticket requires some end-user contributions on how each DBAPI reports error codes, since none of them seem to document it. setting to blue sky until someone is motivated to implement a get_error_code(exception) method for each dialect.

[Former user]

Please give additional info what do you need here? psycopg2's exception contain both code and description as attrs. Some code example will be helpful.

[Mike Bayer]

need "code" and "description" methods for:

psycopg2 MySQLDB Pysqlite2 / sqlite3 cx_oracle adodbapi / etc. firebird / informix

as well as what versions of each DBAPI support them, etc. im fairly certain that we wont have the error code available for some DBAPIs. some DBAPI's might have more attributes (such as severity, etc.), the API should take this into account too.

once thats done, the dialects need to be integrated with DBAPIError; when we make calls to DBAPIError such as in base.py etc., the dialect will need to be passed to the exception constructor, and the dialect will have to be consulted for the appropriate information. dialect classes will probably get a "get_error_attrs(somexception)" method attached which returns code, description etc. as a tuple (or possibly dict, if theres a wide variety of types of information available).

[jek]

I haven't seen any support whatsoever for SQLSTATE in sqlite.

Not sure what the point of propagation would be for any kind of error code other than sqlstate, which supposed to be at least broadly consistent across databases.

[Former user]

Let's make things a bit more clearer for me. What you want here is: 1) some new dialect method which get DBAPI exception as arg, and returns an code and description. 2) add to DBAPIError new constructor arg - dialect and change all raises of DBAPIEror to make dialect to be passed as contructor arg 3) finaly get an "code","description" attrs of DBAPIError

am I right?

one question: when we raise DBAPIError where we could find real DBAPI exception? I look at base.py and find nothing.

[Mike Bayer]

Some additional requests for this functionality are specified in #1587.

[Former user]

zzzeek, it's your one and only consistent and completely repeatable spelling mistake: you always write "propigate" instead of "propagate".

Nitpicking is time wasted, but in this one case I wanted to say something because it's so consistent, the change could be trivial to implement :) -- and because it's really the only one, not the tip of an iceberg at all.

[Mike Bayer]

Replying to guest:

zzzeek, it's your one and only consistent and completely repeatable spelling mistake: you always write "propigate" instead of "propagate".

Nitpicking is time wasted, but in this one case I wanted to say something because it's so consistent, the change could be trivial to implement :) -- and because it's really the only one, not the tip of an iceberg at all.

I appreciate your concern but the "propagate" issue is a dupe, fixed in 4cd99f5536077718b0f80670508d7310f47b4a25 three years ago, so I can only assume you are observing this "consistency" among very old tickets and revisions. I have not misspelled "propagate" since that time, but thanks for the interest !

[Mike Bayer]

To be honest I have no plans to add this feature to SQLAlchemy, the DBAPI simply does not provide this information consistently and it would place too much of a burden on new dialects to add parsers in all cases to locate error codes. Individual DBAPIs don't even use OperationalError/IntegrityError consistently, so the state of exception raises in DBAPI is pretty poor. IMHO applications shouldn't be written using database exceptions as a core flow control component of business logic.