In application development, you want to build systems for the end user and it is important to keep the developer in mind when coding, so the application is usable behind the scenes as well as upfront. At DB Services we have several conventions that we consider to be some of the best practices to adhere to when developing. Let’s take a look.

Error Trapping

One thing that can drastically improve the user experience is user-friendly error trapping. Instead of no indication if an operation fails, giving the user a detailed error message of what went wrong in any given process can go a long way in building user trust. It also empowers the user to fix the problem themselves. Not only that, it can help the developer figure out what went wrong. The key is to be specific in the error message to the point the developer has enough information to know exactly which line of code failed, and on what record it occurred. One way we do this at DB Services is to also include the FileMaker error, after saying specifically what went wrong.

To create this sort of user-friendly error message, Set Error Capture should be turned ON and Allow User Abort should be OFF. Turning off Allow User Abort will make sure the user cannot press the Escape key to halt the running script. Leaving on Allow User Abort could potentially strand the user in some layout they do not expect to see or should not have access to. The user could also put the database in an inconsistent state if the script is in the middle of making changes to data.

Turning on Error Capture will make sure default FileMaker errors do not interrupt the user experience, but also puts the burden on the user to pass along the all-important errors on to the developer.

Proper Context

One of the easiest ways to incorporate error trapping is to run subscripts at the beginning of any script called from the interface to ensure the script cannot be run in an unintended context. The three most common things to check for are the following:

1. Is the user in the correct mode?

2. Are there records in the found set?

3. Can the record be successfully committed?

The last one is important because if field-level validation fires, then the commit will fail, but the script may keep running with unintended consequences.

Record Locking

There are several things that have a high likelihood of going wrong. Set Field is a big one. Be sure to test for record locking whenever a record needs to be updated.

New Record and Delete Record can both fail if a developer in Manage Database locks the table, so be sure to trap after these steps as well. Go To Related Record (GTRR) can be especially dangerous since if there is an error, the script will continue running in the wrong context with potentially devastating consequences to data. On top of this, the GTRR step will sometimes give a false positive error when there really wasn’t an error in the case that you perform a GTRR on a found set. The correct way to trap this step is to ensure the layout before the step is different from the layout afterward. Lastly, any time the application is interacting with systems outside of FileMaker, be sure to pass all errors up to the user. This includes Export Records, Import Records, and also anything like HTTP Post that interacts with the web. Writing error-trapping code might take extra time upfront, but it will save a lot of time when reading and troubleshooting code in the long run.

Quick Tip For Debugging

One way to debug through a script trigger is use the Step Into button on the script debugger. If used on the step that would trigger the script, debugger will step into the script trigger as it fires. So for example if you step into the Commit Record script step, and there is a trigger that will fire every time a record is committed, you can debug through that trigger.

Conclusion

Make things easier on the users and other developers by making code that is robust and readable. Be sure to download our FileMaker Scripting Template database if you would like a copy of our template script and the three error-trapping scripts that come with it.

If you'd like help implementing best practices in your FileMaker system, please contact us and we'd be happy to help with error trapping, debugging, naming conventions, and any other FileMaker needs.