Need an example of how to use "try" and "catch"

Pete pete at mollysrevenge.com
Fri Mar 23 13:34:21 EDT 2012


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 <bobs at 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 at 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>



More information about the use-livecode mailing list