There are several ways people handle errors. #1 Path of least resistance....you assume all is well and ignore them....bad idea but too common #2 Catch as catch can...you put in error handling as you experience them....also a bad idea as it's too similar to #1 #3 Catch with careful thought about what could happen....can be difficult but this is what experienced people do...can still miss things. #4 Catch all...check all return codes and print out something....then do #3 for known error and graceful/proper handling...this is how you learn. #5 Force all possible errors to occur...there's a lot. I don't know anybody that does that.
A combo of #3 and #4 is best IMHO. If you want to be really conservative you could write a wrapper around every sqlite function to randomly return one of its possible error codes. That's would take a lot of time though and I've never heard of anybody doing that. My pet peeve is the lousy error message like Microsoft used to produce "dll not found". What DLL? What error? E.g. File not found or permission problem? Or the very common "cannot open file". What file, why not? Error messages need to be explicit. SQlite is pretty good about it. Developers not so much. -----Original Message----- From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org] On Behalf Of Igor Korot Sent: Wednesday, May 01, 2013 2:00 PM To: General Discussion of SQLite Database Subject: [sqlite] How people test db failures Hi, ALL, I wrote a code that executes fine. There is no memory leaks and no issues. However, trying to check whether my error handling is written correctly, I set breakpoint before accessing db and when I hit it I manually changes the value returned. This is not how it should be done and I feel that the person I'm working with will need to check it at some point. So, how people check whether db failure result in graceful program termination/proper flow? I'm working on the desktop application under Windows and am giving the release version of the program compiled under MSVC 2010. Thank you. _______________________________________________ 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
