On Wed, Sep 5, 2018 at 5:22 AM Richard Hipp <d...@sqlite.org> wrote: > On 9/4/18, Brian Vincent <bra...@gmail.com> wrote: > > Hi, I'm currently writing a Go sqlite package, go-sqlite-lite. I think > it > > provides a good "pure" SQLite experience with Go. > > > > If I want to make sure that the sqlite3_column_* functions never provide > a > > false answer due to an error condition, like a memolry allocation error, > > how should I go about that? The documentation seems inconsistent here. > > > > The documentation about sqlite3_column_*: > > > >> If a memory allocation error occurs during the evaluation of any of > these > > routines, a default value is returned. The default value is either the > > integer 0, the floating point number 0.0, or a NULL pointer. Subsequent > > calls to sqlite3_errcode() will return SQLITE_NOMEM. > > > > The documentation about sqlite3_errcode(): > > > >> If the most recent sqlite3_* API call associated with database > connection > > D failed, then the sqlite3_errcode(D) interface returns the numeric > result > > code or extended result code for that API call. If the most recent API > call > > was successful, then the return value from sqlite3_errcode() is > undefined. > > The sqlite3_extended_errcode() interface is the same except that it > always > > returns the extended result code even when extended result codes are > > disabled. > > > > 1. How can I check the error code if I'm unsure if the column function > was > > successful or not? If it was successful, then the error code is > undefined. > > Just call sqlite3_errcode(). It will return SQLITE_OK if the > sqlite3_column function was successful. If sqlite3_errorcode() > returns something other than SQLITE_OK, then some recent API failed. > It might not have been the sqlite3_column function, but it is still a > failures, so just go with it. >
From my testing, it appears that this information isn't exactly correct. In my tests, when I call sqlite3_column_int64 for example, and it's successful, sqlite_errcode() immediately afterwards is returning SQLITE_ROW, which leads me to believe that it's not setting the error code to SQLITE_OK when it's successful. If I can't trust sqlite_errcode() when it's successful, how can I be sure that it succeeded? > > > 2. Is SQLITE_NOMEM the only error code possible for the sqlite3_column_* > > functions? > > SQLITE_RANGE if you provide an invalid column number. SQLITE_MISUSE > if the prepared statement has been reset or finalized. That is all in > the current implementation, but new error codes might be added in the > future. > > > 3. Is it possible for every single one of the sqlite3_column_* functions > > to fail in this manner? > > I think only the routines that returns TEXT and BLOB use malloc() in > the current implementation. That might change in the future though. > > > -- > D. Richard Hipp > d...@sqlite.org > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
