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.
ScriptErrors.log
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.
The file this Set Error Logging creates is named ScriptErrors.log and it’s written into the user’s Document folder. If the log file already exists, then FileMaker merely appends new data as additional lines to the file. So, we don’t have to worry about maintaining the file or creating a new one each time we need it. There are several things to know about the Set Error Logging script step that may help us leverage it as a tool to expose issues.
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.
Most of these things are pretty important – who, what, where and when. But sometimes, we need a little more detail to flush out a tricky bug and that’s where the “gear option” of the Set Error Logging comes into play. We can maximize the power of the calculation engine to grab all sorts of important stuff, like the state variables, global fields, the current layout name, maybe the contents of an import field or two, and even the client version or operating system. Anything that might help us identify the cause of the problem can be appended to the end of the line via the options.
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.
Error-Free
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.
