*** 22,24 ****
--- 22,32 ----
#define SQLITE_IOERR_FSTAT (SQLITE_IOERR | (7<<8))
#define SQLITE_IOERR_UNLOCK (SQLITE_IOERR | (8<<8))
#define SQLITE_IOERR_RDLOCK (SQLITE_IOERR | (9<<8))
+
+ ----
+
+ *User comment:* I like the idea of more specific result codes, but I think that the specific set of extended error codes listed here is barking up the wrong tree. If the base code is SQLITE_IOERR, telling you _what_ I/O operation failed is not the most useful piece of additional detail you could provide. It'd be more useful to provide the _operating system's error code_ for the failing operation: the =errno= value on Unix, for instance. (The library user cannot safely assume that the value of =errno= when an =sqlite3_*= call returns SQLITE_IOERR, is the value set by the OS-level operation that actually failed. It needs to be saved immediately after the failing operation. Also, =errno= isn't the right thing to look at on Windows, if I remember correctly.)
+
+ I don't know if =errno= values can safely be crammed into the high 24 bits of the result code. It might be better to return them from a separate callback, say, =sqlite3_os_errcode()=, guaranteed to present the OS-level error code from the last operation that returned SQLITE_IOERR. If that were done, I would also recommend that =sqlite3_errmsg()= automatically augment the error string with the equivalent of =strerror(saved_errno)= when appropriate. That would allow library users to present better diagnostics to users without any code changes.
+
+ -- Zack Weinberg <zackw@panix.com> 9 Jan 2007
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|