-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Florian Weimer wrote: > I'm working on something which is supposed to be a foolproof interface > to SQLite. During that, I discovered that SQLite lacks a way to > return errors from a user-defined collation function. Is there > something I've missed?
Nope. If you completely wrap the entire SQLite API you'll find the same thing in some other APIs, or during testing that some error cases are ignored. The SQLite API can't be changed without breaking dynamic linking so that won't happen. > When calling into SQLite and getting back SQLITE_INTERRUPT, I could do some > magic and recover the original error message, but for some types of > errors, this won't work (memory allocation failures, for instance). You can preallocate a structure with an error code and error string buffer. On calling any SQLite API, clear them. On getting an error set them (which does not allocate memory). On return from SQLite call, check your error structure first (ignore any SQLite error code). If you intend to allow the same sqlite3* to be used across threads then your error structure needs to be thread specific. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkkkfZsACgkQmOOfHg372QR4TwCfa5UsHuppQCUwoB6/wb40cXNa VwsAoNb9wp7RbM0dGFjUMft+Kv8NIJBf =xWAL -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
