> On 14 Jan 2016, at 11:55am, Brice Andr? <brice.andre at ams-solutions.be> > wrote: > > I am a little worried with your last post because, I must admint that I do > not take special measures in my application when such errors occur to > guarantee that no more DB access are performed. > > I have thus the following questions :
If you're writing a proper long-term program, check the result codes returned by every SQLite API call. In most cases all you need to do is check to see that the result is SQLITE_OK. Hope this helps. > 1. What would be the proper reaction to SQLITE_FULL, SQLITE_IOERR, > SQLITE_CANTOPEN ? Perform a sqlite3_close ? Just exit the program as is > without touching the database file descriptor ? And once the program has > left, can we perform a sqlite3_open ? At this point there is no need to execute any other sqlite3_ calls. In fact, if you do execute them they'll probably just return another error message. Just print an error message and quit. When the SQLite API is next used to open the file it will know that the file was not closed properly and automatically try to reconstruct an uncorrupted version. This is done without informing the program that anything was wrong. So your question is why should you not try to do this immediately ? The answer is that without the user taking action it's probably going to fail. The original crash might have reported SQLITE_FULL or some other other condition which the user needs to fix before reopening the database. Trying to recover an uncorrupted database while the disk is still full will probably just lead to another crash, so there's no point and, at worst, a possibility of corrupting your database or some other file associated with the program. Another possibility is that the error is something like SQLITE_PROTOCOL, which suggests that you have faulty hardware or faulty file system drivers. Again, immediately reopening the file and continuing may just result in another crash. Worse, it might fatally corrupt the database because the fault in the storage system caused something to overwrite the database file. Again, the correct thing to do here is not to retry, but instead to report the problem to the user and get them to work the fault then decide for themself whether they want to carry on using the program. > 2. What is the exhaustive list of error codes that shall be considered > as fatal ? On this page you will see a full list of all error codes: <https://www.sqlite.org/rescode.html> Near the top you can see that it lists SQLITE_OK (0), SQLITE_ROW (100), and SQLITE_DONE (101) as the only codes which do not represent errors. All other codes (including ones you can't find documentation for) are fatal errors which prevent you from working with the database. So don't test for codes which represent specific errors, instead check for SQLITE_OK and other expected codes then crash for everything else. This is what good SQLite programs do. A normal program should just present a useful error message and quit, perhaps something like "Quitting because a SQLite operation returned error 24.". You might want to generate specific messages for things like a full hard disk but most people don't bother, because there's little chance that the underlying problem is really that the user filled up the disk. Simon.
