On 9 Jul 2013, at 11:54pm, Igor Korot <ikoro...@gmail.com> wrote:

> Shouldn't the engine warn you?
> What I mean is: developer don't know that he fail with the query results
> until further execution or running the program under debugger and explore
> the data.
> I'm not saying it's wrong, I'm just trying to understand the reasoning...

It would indeed be useful to have the developer warned.  But look what it would 
take in this situation.  The call is

int sqlite3_column_int(sqlite3_stmt*, int iCol)

The normal way the API warns of errors is by returning a value other than 
SQLITE_OK.  But this call is unusual: instead of returning a result code it 
returns the value of the field specified.  So to conform with the normal API 
pattern the call would need to be changed to be more bulky and annoying to use 
which everyone would hate.

So the alternative way of warning of an error is an assert.  But SQLite doesn’t 
use this method of warning (except, IIRC, when a compilation option for 
debugging is set).  And an asset is not trappable by the program calling the 
API.  Which would be nontrappable by the programmer, which is not the way 
SQLite normally does things.  So again, you have somthing which wouldn’t 
conform to the usual SQLite way of doing things.

So there’s no good way to deliver what would be this useful warning without 
changing expectations about the SQLite API.  The only elegant thing to do is to 
rely on the programmer calling sqlite3_column_count() in the weird and unusual 
situation where they don’t know how many columns to expect.

By the way, does anyone understand the difference between 
sqlite3_column_count() and sqlite3_data_count() ?  I mean, I can read the 
definitions, but why are they both provided ?  Is one more useful than another 
sometimes ?

Simon.
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to