Title: Use sqlite3 extended error codes
Type: enhancement Stage: patch review
Components: Extension Modules Versions: Python 3.6
Status: open Resolution:
Dependencies: Superseder:
Assigned To: Nosy List: Dima.Tisnek, ghaering, palaviv, r.david.murray
Priority: normal Keywords: patch

Created on 2015-05-07 09:19 by Dima.Tisnek, last changed 2019-06-07 00:00 by terry.reedy.

File name Uploaded Description Edit
24139.patch palaviv, 2016-08-30 18:19 review
Pull Requests
URL Status Linked Edit
PR 1108 open palaviv, 2017-04-13 10:02
Messages (6)
msg242710 - (view) Author: Dima Tisnek (Dima.Tisnek) * Date: 2015-05-07 09:19
Let's fetch extended error codes from SQLite, information contained is not particularly interesting to the user, but may be invaluable in debugging!

Current behaviour:

For example, consider that extended error was SQLITE_READONLY_DBMOVED, it would be set in without explicit detail string.

Python will call sqlite3_errcode() which will strip extended information via `& errMask` in

Python will then call sqlite3_errmsg(), and the error message will be according to truncated (simple) error per:

P.S. there are a few cases where sqlite3 internally sets both error code and message, in those cases, current Python module (presumably) reads out the error message correctly. For example
msg242714 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2015-05-07 13:41
It seems reasonable to provide as much error information as is available, one way or another.  Would you like to work on a patch?
msg273949 - (view) Author: Aviv Palivoda (palaviv) * Date: 2016-08-30 18:19
Attached is a patch to enable the extended error codes. This patch should be dependent on issue 16379.
Without returning the sqlite error code in the exception the extended error code does not reveal any information not currently available. As you can see in there are messages only for the non-extended error codes and that is what is exposed now.
msg274008 - (view) Author: Dima Tisnek (Dima.Tisnek) * Date: 2016-08-31 09:59
Aviv the patch makes in itself.

Are the changes in the other ticket needed to implement new tests?
Or is it possible to include tests here?
msg274009 - (view) Author: Dima Tisnek (Dima.Tisnek) * Date: 2016-08-31 10:02
I meant "the patch makes sense in itself".
msg274065 - (view) Author: Aviv Palivoda (palaviv) * Date: 2016-08-31 20:12
> Are the changes in the other ticket needed to implement new tests?
> Or is it possible to include tests here?

It is not possible to add any tests to this issue before exposing the error code. I will implement new tests when issue 16379 will be resolved.

> Aviv the patch makes in itself.

I think that this issue should be dependent on issue 16379 as the behavior of the sqlite module will no be changed after this patch until issue 16379 is resolved. In addition there will be some "rebase" issues that will need to be solved.
Date User Action Args
2019-06-07 00:00:51terry.reedysetpull_requests: - pull_request13749
2019-06-06 19:17:57taleinatsetstage: patch review
pull_requests: + pull_request13749
2017-04-13 10:02:14palavivsetpull_requests: + pull_request1249
2016-08-31 20:12:15palavivsetmessages: + msg274065
2016-08-31 10:02:11Dima.Tisneksetmessages: + msg274009
2016-08-31 09:59:52Dima.Tisneksetmessages: + msg274008
2016-08-30 18:19:28palavivsetfiles: + 24139.patch

nosy: + palaviv
messages: + msg273949

keywords: + patch
2015-05-07 18:29:14ned.deilysetnosy: + ghaering
2015-05-07 13:41:18r.david.murraysetnosy: + r.david.murray

messages: + msg242714
versions: - Python 3.5
2015-05-07 09:19:35Dima.Tisnekcreate