Column methods, error and NULL handling

[bvinc]

I've learned a lot about the sqlite3_column_* functions and redid my methods in go-sqlite-lite.

• sqlite3_column_blob and sqlite3_column_text might fail with the NOMEM error.
• sqlite3_column_text returns a NULL pointer in both error cases, AND when the actual column is NULL. The only way to tell the difference is to check the column type beforehand.
• sqlite3_column_blob returns a NULL pointer in error cases, but also when the column is NULL, but ALSO when the column is a zero length blob. The only way to tell the difference is to check the column type beforehand and also check the length beforehand.
• All the other column functions probably won't fail, but they can, such as when the index is out or range, but since they don't return an error, there is no way to tell.
• You may think that you can call sqlite3_errcode to check to see if they failed, but that doesn't work, because when the previous function was successful, sqlite3_errcode's value is undefined.
• To make matters worse, checking the column type is only valid as long as they have not performed any data conversions on the column. If they have, then the column type becomes undefined.

So it seems like, if you care about proper error handling, you have to cache the column types before the user has a chance to do any data conversions. You have to check if the column type is NULL in your cached values. You have to check to see if the index value is out of range manually. Don't call sqlite3_column_blob until you've checked to see if the length is non-zero. Only check sqlite3_errcode after you've checked all of these things and sqlite3_column_text or sqlite3_column_blob returns NULL.

Do with this information what you will.

[crawshaw]

Thanks for the information. It looks like I have a couple of cases I have not covered.

I wish we could combine forces on this, but there's a bit of divergence between our drivers that I'm not sure how to resolve.