On Tue, Sep 4, 2018 at 1:31 PM Keith Medcalf <kmedc...@dessus.com> wrote:
> > Well, that is not exactly true. If you attempt to retrieve the column > values properly, either no errors can occur or if they do, they are obvious. > > 1) Query the column_type > 2) If the column_type is SQLITE_NULL then return a NULL indicator and > stop processing these steps. > 3) If the column_type is SQLITE_INTEGER > a) Retrieve the column value using the column_int64 function, return > that result and stop processing these steps. > 4) If the column_type is SQLITE_FLOAT > a) Retrieve the column value using the column_double function, return > that result and stop processing these steps. > 5) If the column type is SQLITE_TEXT > a) Retrieve the column value data pointer using the column_text or > column_text16 > b) If the returned pointer is NULL, then an error has occurred and > you can use the errcode() function to find out what it was. > c) If and only if the returned pointer is not null then you can use > the corresponding column_bytes or column_bytes16 to get the length of the > data. > d) Return the resulting pointer and length (or copy it, or whatever) > and stop processing these steps. > 6) If the column type is SQLITE_BLOB > a) Retrieve the column value pointer using column_blob > b) If the returned pointer is NULL, then an error has occurred and > you can use the errcode() function to find out what it was. > c) If and only if the returned pointer is not null then you can use > column_bytes to get the length of the data. > d) Return the resulting pointer and length (or copy it, or whatever > and stop processing these steps. > > The only time it is possible for an error to occur is if *YOU* are > requesting *DATA CONVERSION*, usually to or between byte-sequence (text) > formats. This is easy for you to detect because: > > If the column_type is not SQLITE_NULL and the output pointer of the > function IS NULL, then an error has occurred. > Otherwise, no error has occurred. > > Thanks for this reply. I think this is my answer. Dr Hipp suggested that sqlite_errcode would return SQLITE_OK after a column function succeeds, otherwise it would return other errors such as SQLITE_RANGE or SQLITE_MISUSE. But, it doesn't appear to be the case that the error code is set to SQLITE_OK on success. So it seems that the only way to differentiate an error case from a NULL value is to check the column type beforehand as you suggested. It also seems that the only way to detect that the column number is out of range is for me to check the ColumnCount beforehand and do the checking myself. To be honest this API seems a little goofy and I would love to see column functions that have the ability to return an error. But I can work with this API, as long as I have a guarantee that the error code is set when the column type is not SQLITE_NULL and sqlite3_column_text and sqlite3_column_blob return a null pointer. Dr. Hipp (and the documentation) say that SQLite reserves the right to possibly use malloc in the future for sqlite3_column_int, int64, double, and possibly fail with SQLITE_NOMEM. But I don't see how I could ever know if it's correct to check sqlite3_errcode, so I don't see how this is possible. I also need a guarantee that these functions cannot fail (after I've checked the column count and column type). These guarantees are not very clear in the documentation. Thanks for your help. > > --- > The fact that there's a Highway to Hell but only a Stairway to Heaven says > a lot about anticipated traffic volume. > > >-----Original Message----- > >From: sqlite-users [mailto:sqlite-users- > >boun...@mailinglists.sqlite.org] On Behalf Of Simon Slavin > >Sent: Tuesday, 4 September, 2018 12:03 > >To: SQLite mailing list > >Subject: Re: [sqlite] sqlite3_column_* with error handling > > > >Your question has been asked earlier this year, and no solution was > >posted. I'm interested to find out whether things have improved. To > >summarise the earlier post: > > > >1) sqlite3_column_int() returns the value stored in that column, or 0 > >if an error occurred. > > > ><https://sqlite.org/c3ref/column_blob.html> (last para) > > > >2) If the value returned is 0, there's no way to tell whether it's > >because of an error or 0 really is the value returned in that column. > > > >3) Presumably you're meant to call sqlite3_errcode() to find out > >which it is. > > > >4) However, if the most recent API call was successful, then the > >return value from sqlite3_errcode() is undefined. It could be an > >error code. It could be 0. > > > ><https://sqlite.org/c3ref/errcode.html> (first para) > > > >5) Similar problems occur with some other sqlite3_column_*() > >functions. > > > >6) As a result, the programmer cannot perform error-checking for > >these functions. > > > >Simon. > >_______________________________________________ > >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 > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
