Keith Medcalf wrote: > IF ResultCode == A_OK YipeeKiAiii else OhShitItDidntWork; > > Seems pretty straightforward to me. You handle the result codes you > know what to do with,
There is a difference between things I don't personally know how to handle and things that the SQLite authors would consider "permanent" errors (where "permanent" is appropriately scoped e.g. to the level of the function call, the sqlite3_stmt*, the sqlite3*, or so on). My ignorance of the API details is not a justification for writing a crappy client. I would like to cure my ignorance, and the docs are insufficient in that regard AFAICT. Hence my question to this forum. > and everything that remains means your program should explode > immediately and very very loudly dumping ALL relevant information (ie, > error code, statement, inout data, output data, etc.) SQLite is not the center of my universe. The layer using it is not at the center of the program in which it resides. The program I am writing is a high-availability, mission-critical system. Barfing because of an SQLite error is unacceptable in my case, especially if the only reason the program is barfing is because the programmer who wrote it was a dummy (or at least more of a dummy than he should have been:-). And whether it barfs is sort of beside the point. If I restart my program and give SQLite the same series of commands, should I expect it to fail in the exact same way, or should I expect its behavior to change? Depends of course on the state of the system and on the particular series of calls. If the documentation were sufficient, then it would allow me to reach the appropriate conclusion. I would first like to know exactly what the *authors* expect to be returned in various cases, so that I can code to that expectation. > In other words, there is no point checking for error conditions > which you cannot handle. Instead you just die. Quickly, noisily, > and immediately. There is no point checking for the error message > SQLITE3_CPU_REGISTER_HIT_BY_COSMIC_RAY if there is nothing that you can > do about it. Every error that you cannot handle is a fatal error, and you > should die accordingly. I can handle every kind of error. It's just a question of how. I don't know how in many cases, because I don't understand the semantics of the error codes, in turn because (I think) the documentation is insufficient. It is not healthy to bake such ignorance into the application if I can help it -- again, I would rather just cure my ignorance (preferably not by digging through the code and reaching my own flawed conclusions about it). -- Eric A. Rubin-Smith _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
