Keith, On Thu, May 2, 2013 at 9:44 PM, Keith Medcalf <kmedc...@dessus.com> wrote:
> > > My question was a little different. > > > I am developing desktop application which utilizes SQLite. At some point > > in time my customer will want to know what happen when the DB operation > > breaks. > > This depends on your definition of "breaks". > Let me give you an example. I start the transaction, do couple of inserts and then I get an I/O error. In this case I need to rollback tell the user about failure and go back to the screen I started the transaction from. Or the simplest one - the database is moved and inaccessible. If it happens on the start, just tell the user and exit the program. If it happens during the program execution, again tell the user that current operation failed and go back to the screen that originated the operation. > > > How do people prove to their customers that no matter what the software > > will either finish gracefully or will not break, crash or anything to > that > > matter? > > Oftentimes, it is preferable to "break" or "crash" rather than do > something in error -- or worse yet fail to detect the error and proceed > merrily but incorrectly. > > > So far the guy tested the program and he made sure that working with DB > > was OK if everything succeeds. But now I want to let him know that he can > > setup the environment and try check what happen if something fails. > > The answer to this depends on what failed, and if you can anticipate such > failure being a valid outcome of what you are doing. > > > How do you achieve something like this? > > If everything succeeds, you are fine. If it fails in an anticipated way, > then you deal with it in accordance with your design. If the failure is > unanticipated, you vomit noisily presenting sufficient information to > diagnose and repair the problem. If appropriate, you add specific handling > for the error that you didn't anticipate happening once you know the > circumstance under which it occurs and can validate that the specific > circumstance has occurred so that your fault handler is dealing with the > fault correctly. > > Of course, if the "error condition" is anticipated, then it is not an > error, is it? > > Having something which guarantees consistency in the face of unexpected > failure, in other words ACID, makes the issue not really much of an issue > at all since it should be impossible for sudden "de-rugging" (ie, crash or > killing the process) of the application at any time to cause corruption and > inconsistency (if it can, then you have designed your application badly). > > You can handle it in the same way that Apple does: crash with a little > comic bomb on the screen, then display a picture of a little application > with a thermometer in its mouth, then after a time simple restart yourself > over cleanly. > Well I'm handling it. Problem is, how do I prove to the customer/user that it is working as expected no matter what? Thank you. > > --- > () ascii ribbon campaign against html e-mail > /\ www.asciiribbon.org > > > > > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
