2 of 2 people found this helpful
Set Error Capture maintains its state until the script ends or it's changed.
A parent Set Error Capture will persist to subscripts and subscripts will persist into parents.
Thanks David - would be nice if Filemaker to add that to the manual.
There is "When Set Error Capture is used in a script that contains a sub-script, errors from the sub-script are captured as well." But it could be clearer.
In my opinion, this is a step that is often used when it should not be used. There are specific places to use it, all server side scripts probably need it, for example and we want to selectively suppress certain dialogs such as the infamous "no records found" dialog or to better handle when a user clicks "cancel" in a system dialog, but I've seen developers just make this step the first step of every script.
I've then had to debug complex situations in those scripts that trace back to an unanticipated error being concealed by set error capture while allowing the script to attempt to run in a state that produces incorrect results--even modifying data in a record instead of entering find criteria.
So in normal, client side scripts, I usually put set error capture [on] in place just before I need it and then put in set error capture [off] immediately after I no longer need it.
I see it now - thanks David - sorry about that.
It reads: When Set Error Capture is used in a script that contains a sub-script, errors from the sub-script are captured as well.
suggestion: When Set Error Capture is SET in a script that contains a sub-script, errors from the sub-script are EFFECTED as well.
Thanks philmodjunk - I limit it to setting it on just prior to a Perform Find and off immediately after.
I turn Set Error Capture [ On ] at the beginning of every single script. Leaving it on is forcing users to do my debugging.
I would never, ever do that. If an error occurs that I have not accounted for, I NEED to know and my users are the ones to tell me. And that script should not then be permitted to run given that an error has occurred. Otherwise they run a script with an error, perhaps repeatedly and do God knows what damage to the data in the system as they may not even know that anything is wrong. That's really not asking them to do the debugging. It gives them the means to promptly report a problem so that I can do the needed debugging.
Consider this actual case history:
We were seeing fields mysteriously change to show data that was clearly find criteria entered while in Browse mode. It happened very rarely, but my predecessors could not figure out why it was happening. They finally started modifying some scripts (that all had set error capture as the first executed step), that, after entering find mode, would check to see if the window was actually in find mode and show a custom dialog if it wasn't. The code looked like this:
Enter Find Mode [ ]
If [ get ( windowmode ) =....
I looked at that and wondered how the heck the script could ever fail to be in find mode immediately after enter find mode is executed, but then a help desk ticket (how we support this system is via zen desk), was routed to me where a user was getting the custom dialog and reporting all kinds of problems along with it.
After more than an hour tracing several different scripts and talking to the user reporting the trouble, here's what I found out:
A data validation error was keeping the script from entering find mode.
The user edited data in a way that would trip the validation error once the record was committed, but then clicked a button to run the script without any such commit. The script, with error capture on then entered find mode. That step committed the record and the validation error occurred. This error kept the window from entering find mode but with set error capture on, continued to execute. Thus, before my colleagues put in that test for find mode, the script would use set field to specify find criteria, but with the window still in Browse mode, it modified data instead of specifying find criteria.
It's really just a fact of life that with set error on or not, our users will be helping us to debug the solution. I call that user feedback. We aren't perfect, FileMaker isn't perfect nor are the systems on which we run our solutions. Problems will occur and unless the user knows that a problem occurred, they can't inform us of that fact and then the problem cannot be dealt with. Those error dialogs that interrupt a script thus may be a crucial part of how we support our users to keep the solution as free of error as possible.
Frankly, the inconsistent way that FileMaker handles script execution errors and the lack of any kind of "error handler" that could be used to trap all execution errors in a script that might occur at any point within that script is one of the more critical short comings of FileMaker solutions. I've said as much in a presentation at FileMaker Inc in Santa Clara and have posted a product idea on this issue.
I'm glad that works for you and your coding style.
That's not my preference however.