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.
---
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-
>[email protected]] 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
>[email protected]
>http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
[email protected]
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
