In a previous article, we chatted about FileMaker error codes and made a point to emphasize the importance of keeping our eyes open during development. We have to be ever vigilant within the obscure areas of our solutions where things might break. Sometimes, we have to push our solutions to the brink in the hopes of revealing a weakness that may have otherwise gone unnoticed. We also took a look at a few techniques for trapping errors and then organizing them so that we can deal with them appropriately. This post will explore a new tool that Claris gave us a few versions back called Set Error Logging. This tool allows us to take error trapping to a whole new height.
Set Error Logging is a simple script step that allows us to write errors in scripts to a log that resides on the user's computer or iOS device. Invoking this command in a script turns on a process that logs all the errors in any of the scripts of that file until we either close the file or Set Error Logging to off. So if we're having a problem with a scripted workflow that only seems to occur at certain times of the day or maybe only for a particular user, we can run this operation in the background taking note of any errors that happen, right on that user's device.
So, what's written to this file, you may ask? Well, some standard data as well as anything we like. Let's start with the standard stuff.
In the above example, we added the layout name, the table the layout is associated with and what mode the user was in when the error occurred. The Window Mode was placed at the end for two reasons. Often we don't account for scripts being executed in Find Mode. And in FileMaker, Find Mode is such a subtle transition, it's not always reported by users during the interviews we have with them.
As we said before, the ScriptErrors.log file is created and/or updated directly in the user's Document folder, so every user has their personal log. Therefore, we could create a scripted process to gather these logs and send them to ourselves or add the info to our solutions with just a few script steps. Simply by using the Open Data File script step and get(DocumentsPath), with the ScriptErrors.log as its path, we can capture each file's info and store it in our database or pass it to an email. With this information, we'll be well on our way to getting to the bottom of the scary bugs in our applications.
To sum things up, FileMaker gives us some really good tools to make the process of creating error-free a lot less screechy a ride. Having said all that, we can't be too afraid or too proud to use them.
We're full of helpful FileMaker development information, such how to move data from repeating fields and how to manage and customize images. Check out more of our tips and tricks for custom app developers.
This article is also published on FileMakerProGurus.com.