On Jan 7, 2016, at 6:04 PM, Darren Duncan <darren at darrenduncan.net> wrote: > > On 2016-01-07 4:55 PM, Warren Young wrote: >> 2. There is no ?preview? mechanism. > > The current method of binding is correct. All we really need is that the > debug logging layer include both the SQL of the prepared statement AND a list > of the bound values when the execute failed
By that logic, it would be okay to design a C compiler that emitted only line numbers as error numbers, and gave those line numbers as cpp(1) output line numbers, not source input line numbers. That is, if stdio.h is 5kSLOC and you make an error on line 5 of your hello world program, it should complain, ?hello.c:5005: error?. After all, the programmer has all the information necessary to subtract out the #included files? offsets, and then go look at line 5 in the program to determine what went wrong. SQLite error handling should improve the same way our C and C++ compilers have. Given: include <stdio.h> (missing ?#"!) Ancient Unix V7 cc says: hello.c:1: Expression syntax. Yes, very helpful. (Not!) pcc on the same box spits out about half a dozen errors for that line, none of which tell you what is wrong. gcc 4 says: hello.c:1: error: expected ?=?, ?,?, ?;?, ?asm? or ?__attribute__? before ?<? token It?s not as pointlessly noisy as pcc, but it?s still not terribly useful. clang says: hello.c:1:1: error: unknown type name 'include' include <stdio.h> ^ The arrow points you right at the error. Wouldn?t it be nice if SQLite were more like clang in this regard?
