Bob, Maybe I'm missing something but you seem to be saying there are some database errors that can only be detected by using try/catch, not by checking the result or the "revdberr" string.
Taking your example of a database going away, I just created a small db, opened it in LC, then deleted the db file. Any further accesses to the db in LC came back with an error without using try/catch, so I'm not understanding why a try/catch is necessary. Not saying try/catch might not be necessary, just trying to understand if I need to start using that approach. My test was done using sqlite so maybe other SQL variants is where try/catch is needed or perhaps it's due to your use of SQLYoga. Pete On Thu, Mar 22, 2012 at 4:10 PM, Bob Sneidar <b...@twft.com> wrote: > When you are in a standalone, a runtime error that would halt execution > might be fatal. Try/Catch allows you to handle the error gracefully without > presenting the user with an ugly dialog and a QTD afterwards. You can > politely inform the user that something has gone wrong and you have to exit > the application, after tidying things up a bit if necessary. > > Databases can just go away sometimes, like the IT guy deciding it's time > to update the servers and restart them while the user is working late on an > important project. Setting a repeat loop around a try/catch construct > allows you to attempt a reconnect a certain number of times, or present the > user with a Retry/Cancel dialog, allowing you to clean up and exit > gracefully if necessary. > > As a case in point, I was having a problem with a low level broadcast > storm which was causing the uplinks on our switches to reset (they are > designed to do that). Anyone who uses Microsoft SQL knows this can be > fatal, depending on how the software is written. Our accounting software > was not very well written, and as a result, the end user was subject to a > never ending stream of error dialogs allowing a cancel, retry or abort! > None of them exited gracefully. ICK!! Had the developer accounted for the > possibility that the user could be disconnected from the database, and > provided a graceful exit, my reputation would not now be so tarnished, > because they all blamed me of course. :-) To the accounting girl's credit > however, they did make me brownies when I found the source of the broadcast > storm and fixed it. > > Bob > > > On Mar 22, 2012, at 3:31 PM, Pete wrote: > > > Sorry to keep this thread going but I'm trying to figure out if I should > be > > using try/catch more, particularly for database calls. > > > > As far as I know, you can tell if any of the standard rev db calls fail > by > > checking their returned value or the result. Are there circumstances > where > > that's not the case or does SQLYoga silent about errors? > > > > I have experienced silent datagrid problems that were only revealed by > > enclosing the datagrid access statements in try/catch. > > > > Pete > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > > -- Pete Molly's Revenge <http://www.mollysrevenge.com> _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
