* 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().

New changeset 0eec6276fdcdde5221370d92b50ea95851760c72 by Serhiy Storchaka in branch 'main':
bpo-44859: Improve error handling in sqlite3 and and raise more accurate exceptions. (GH-27654)
https://github.com/python/cpython/commit/0eec6276fdcdde5221370d92b50ea95851760c72

* 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().

New changeset 4674fd4e938eb4a29ccd5b12c15455bd2a41c335 by Erlend Egeberg Aasland in branch 'main':
bpo-44859: Raise more accurate exceptions in `sqlite3` (GH-27695)
https://github.com/python/cpython/commit/4674fd4e938eb4a29ccd5b12c15455bd2a41c335