On 14 Jan 2016, at 1:02pm, sanhua.zh <sanhua.zh at foxmail.com> wrote:
> I don?t mean to be rude. BUT, I can?t agree with your opinion, Simon. I will present some arguments on my side. I hope you take this as cultured conversation and not an outright rejection of your points. > 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be > treated as fatal errors. > As an example, SQLITE_BUSY indicates that this op is temporarily failed, but > it can be done later. (Note that sometimes you should not retry forever.) I would say that the programmer should have set an appropriate timeout value: <https://www.sqlite.org/c3ref/busy_timeout.html> If you do this then SQLite will handle any temporary problem for you. If you are still getting SQLITE_BUSY, then I suspect you have a locking problem which cannot be solved inside your program. > Another example, while SQLITE_FULL,manually cleaning your pragram cache to > make some free space might be a better way than crash your app. In modern computer use the user is probably running many programs at the same time. So your program cache may be inside your SQLite program, but filling up the disk may cause the user's word processing program to crash and losing important work. But this will happen without your SQLite program getting any error message. If you have created a big cache in your program you cannot wait until the SQLite program gets an error message before realising that it is causing problems for your user. > 2. Quit while get error is also not a great enough idea. Because not all > pragram is a command line tool. It can be a user-oriented application instead > of a developer-oriented tool. Users don?t wish to meet a crash. I'm not sure what you expect a user application to do when it cannot continue and will lose any new data typed into it. What should it do instead of displaying an error message and quitting ? > So, find out how SQLITE_FULL leading to SQLITE_CORRUPT SQLITE_FULL is itself a fatal error. Why are you waiting to get another error message before taking action ? Simon.