Approaches to errors during development generally break down into two methods. Like defensive driving, the first method attempts to avoid errors from occurring. The second method attempts to deal with errors that occur and find appropriate ways to minimize the effects. Good solutions find a balance between both methods.
Typically errors occur in the context of scripting through unexpected behavior, although other areas of FileMaker can result in unexpected behavior, including case statements, conditional formatting, autosizing of layout objects, charting behavior, and security. In this brief article we’ll focus on scripting errors, although the methodology applies to all areas: test all features from as many perspectives as possible.
FileMaker Error Codes
FileMaker harbors built-in detection and notification of errors. Internally, these take the form of numerical codes, and each code bears a matching text description in FileMaker’s error reference in the Help file. Over 200 built-in error codes exist, including the “no error” error code of zero (0), and the common search result error code of 401, indicating no records were found.
Although one might believe it counter-intuitive to include these as error codes, when checking for errors such behavior, it is invaluable. They are like the Hound of the Baskervilles, which failed to bark at a critical moment and provided the clue to solve the mystery.
FileMaker’s own internal codes will spur various dialog messages. Users trying to modify a record being modified by another user will see a dialog to this effect. Scripts that modify records may run into the same issue, but with no one monitoring the script, such dialogs will pause action until they are resolved.
Trapping for Errors
By taking control of FileMaker’s error notification through the Set Error Capture [On] script step prior to actions that may cause errors, developers can plan for possible errors and deal with them below the surface, allowing scripts to ignore errors or set them aside until later.
There are various levels of handling errors that developers can use in solutions, if they accept the fact that errors are possible, even in the best of circumstances. First, suppress all or certain error notifications. Second, assuming human interaction is possible, display alerts in dialog windows to users and guide resulting action from users through the script.
This could mean requiring the user to take action based on the alerts, and handle the user’s possible action(s). In addition, developers could build in processes that log all errors in a table for subsequent debugging.
Leave a Reply