You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
sqlite3: some code paths ignore exceptions #108083
connection_finalize() clears any exception with PyErr_SetRaisedException(), but pysqlite_connection_close_impl() must not ignore silently error, since here we are talking about a raised Python exception! The function must report if an exception was raised. Then the caller is free to ignore it or not.
I suggest to continue ignoring it in finalize, but then write a separated PR to log the "unraisable exception".
I have not found a test for failing Connection.close(). Would it be possible to write one? Maybe in a separate issue.
It should be possible to force the implicit ROLLBACK in .close() to fail using some kind of database lock trick. Perhaps we could use a similar trick as in test_ctx_mgr_rollback_if_commit_failed.
sqlite3_close() can be made failing in many ways, but sqlite3_close_v2() tries hard to return SQLITE_OK, so it may be not so easy to provoke a failure.
Yes, sqlite3_close_v2() returns SQLITE_OK if it is given a valid database handle. sqlite3_closecan return an error, but it is hard to see how to be able to trigger that from the constructor; I'm not sure it is possible. We could just as well use sqlite3_close_v2() in the constructor.
If there is no easy way to trigger an error at exit or to report it, I suggest to just give up and close the issue.
I don't think there is; the case is the constructor, between the sqlite3_open_v2 call and the following four goto error jumps. I don't see how we can provoke an error there.
Activity
pythongh-108083: Don't ignore exceptions in sqlite3.Connection.__init…
serhiy-storchaka commentedon Aug 18, 2023
I have not found a test for failing
Connection.close(). Would it be possible to write one? Maybe in a separate issue.gh-108083: Don't ignore exceptions in sqlite3.Connection.__init__() a…
[3.12] pythongh-108083: Don't ignore exceptions in sqlite3.Connection…
erlend-aasland commentedon Aug 19, 2023
It should be possible to force the implicit ROLLBACK in
.close()to fail using some kind of database lock trick. Perhaps we could use a similar trick as intest_ctx_mgr_rollback_if_commit_failed.[3.12] gh-108083: Don't ignore exceptions in sqlite3.Connection.__ini…
erlend-aasland commentedon Aug 23, 2023
Keeping this open until tests are added.
serhiy-storchaka commentedon Aug 23, 2023
sqlite3_close()can be made failing in many ways, butsqlite3_close_v2()tries hard to return SQLITE_OK, so it may be not so easy to provoke a failure.https://www.sqlite.org/c3ref/close.html
erlend-aasland commentedon Aug 23, 2023
Yes,
sqlite3_close_v2()returnsSQLITE_OKif it is given a valid database handle.sqlite3_closecan return an error, but it is hard to see how to be able to trigger that from the constructor; I'm not sure it is possible. We could just as well usesqlite3_close_v2()in the constructor.vstinner commentedon Aug 23, 2023
If closing a connection can fail but the
sqlite3_close_v2()ignores errors, is there another API to "flush" a connection and reports errors?If there is no easy way to trigger an error at exit or to report it, I suggest to just give up and close the issue.
erlend-aasland commentedon Aug 24, 2023
I don't think there is; the case is the constructor, between the
sqlite3_open_v2call and the following fourgoto errorjumps. I don't see how we can provoke an error there.Closing this as resolved.
vstinner commentedon Aug 24, 2023
Thanks, nice sqlite3 enhancement! Ignoring exceptions silently is never a good idea.