Repository navigation
Improve some sqlite3 errors #89022
Description
Activity
- MemoryError is now raised instead of sqlite3.Warning when memory is not enough for encoding statement to UTF-8 in Connection.__call__() and Cursor.execute().
- UnicodEncodeError is now raised instead of sqlite3.Warning when statement contains surrogate characters in Connection.__call__() and Cursor.execute().
- TypeError is now raised instead of ValueError for non-string script in Cursor.execute().
- ValueError is now raised for script containing NUL instead of truncating it in Cursor.execute().
- Correctly handled exceptions raised when getting boolean value of the result of the progress handler to bool.
Also added many tests which cover different exceptional cases.
There is also a problem with the sqlite3.InterfaceError raised when bind parameters with message "Error binding parameter XXX - probably unsupported type." It is raised not only for unsupported types, but:
- For too large integers (outside of the range of signed 64-bit integers).
- For too large strings and blobs with size <= INT_MAX but larger than the SQLite limit (1_000_000_000 by default). But OverflowError is raised for size >= INT_MAX.
- When memory error or any other error occurred inside SQLite.
Entries 3 and 4 are about Cursor.executescript(), not Cursor.execute().
- sqlite3.ProgrammingError is raised for SQLITE_MISUSE. IMO, sqlite3.InterfaceError, is more appropriate.
- In case of too large integer values, OverflowError is raised on bind, but sqlite3.DataError is raised on UDF return. Using sqlite3.DataError in both cases would be more aligned with PEP-249.
- Too long strings/blobs raise OverflowError. Consider raising sqlite3.DataError instead.
- For non-contiguous (blob) buffers, we overwrite the BufferError with ValueError. Instead of overwriting BufferError, we should consider chaining with sqlite3.DataError.
- Consider raising sqlite3.Warning when nan is implicitly converted to NULL by SQLite
- In pysqlite_statement_create(), consider raising sqlite3.ProgrammingError iso. sqlite3.Warning when more than one statement is executed
- In pysqlite_statement_create(), consider raising sqlite3.DataError iso. ValueError for queries with null characters
Also, for SQLite 3.7.17 and above, we should raise sqlite3.Warning for error codes SQLITE_NOTICE and SQLITE_WARNING.
Also, for SQLite 3.7.17 and above, we should raise sqlite3.Warning for error codes SQLITE_NOTICE and SQLITE_WARNING.
Er, forget that. Neither are returned by any SQLite C interface, at the moment. They can (currently) only be used as the first argument to sqlite3_log().
- added a commit that references this issue
on Apr 15, 2022 - added a commit that references this issue
on May 4, 2022 The following PRs have improved this issue:
- bpo-44859: Improve error handling in sqlite3 and change some errors #27654
- bpo-44859: Raise more accurate exceptions in
sqlite3#27695 - gh-69093: improve sqlite3.Connection.blobopen() error handling #91571
- gh-89022: Improve sqlite3 exceptions related to binding params and API misuse #91572
Suggesting to close this. If other inconsistencies are discovered, we can open a new issue.
Reacted by Jelle ZijlstraThanks for bringing this up and pushing it, Serhiy.
There is one inconsistency remaining:sqlite3.Cursor.executeraisesqlite3.Warninginstead ofsqlite3.ProgrammingErrorif multiple SQL statements are supplied. IMO, we should fix this.Actually, it is not raised in theexecutemethod implementation; it is raised during statement creation instatement.c.Forget it; I already fixed this ☕ ☕ ☕
sqlite3#27695Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields: