Right now, whenever this library gets an error code from a SQLite operation, it drops it on the floor and calls lastError, which in turn calls sqlite3_errcode, sqlite3_extended_errcode, sqlite3_errmsg, and sqlite3_system_errno. These functions all operation on the connection itself (sqlite3* instance), and thus don't work correctly if the connection was already closed via sqlite3_close_v2.
It doesn't really make sense to call sqlite3_errcode, since we already know what the error code was. Meanwhile, the call to sqlite3_extended_errcode can also be avoided by calling sqlite3_extended_result_codes during connection setup. That way all the API calls will return the extended error code in the first place.
By fixing both of these, it means we can still return the error code and extended error code, even in cases where the connection itself was already closed.
Right now, whenever this library gets an error code from a SQLite operation, it drops it on the floor and calls
lastError, which in turn callssqlite3_errcode,sqlite3_extended_errcode,sqlite3_errmsg, andsqlite3_system_errno. These functions all operation on the connection itself (sqlite3*instance), and thus don't work correctly if the connection was already closed viasqlite3_close_v2.It doesn't really make sense to call
sqlite3_errcode, since we already know what the error code was. Meanwhile, the call tosqlite3_extended_errcodecan also be avoided by callingsqlite3_extended_result_codesduring connection setup. That way all the API calls will return the extended error code in the first place.By fixing both of these, it means we can still return the error code and extended error code, even in cases where the connection itself was already closed.