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