The previous sections suggested a few approaches you can follow to make your programming easier to troubleshoot. But errors will happen. As you build systems, you need to expect errors, and plan for how to handle them. Many programmers (too many) make the mistake of assuming that things will always work correctly. Their programs behave perfectly well, as long as nothing unexpected happens. But when a user enters data they didn't expect, or a network connection drops, suddenly the program ceases to behave gracefully, and its behavior becomes what we call (charitably) "undefined."
Let's take a simple example. You have a FileMaker system that periodically needs to import data from some other source. Imagine that the FileMaker system contains a table of manufacturers, and the manufacturer data is actually being fetched from an Oracle system via an XML Import. The update is intended to be a destructive update, meaning that the new data completely replaces the old. You want to perform all this work via a script, so you write the following (nai[um]ve) script:
Go to Layout ["Manufacturers"] Show All Records Delete All Records [No dialog] Import Records [No dialog: http://my.mfg.com/mfg_update?code=3]
That seems right. Find all the current manufacturers, delete them, and import the new ones. But it's not right; it's dead wrong. What if the import step fails (for example, because the web server at http://my.mfg.com is down for maintenance)? Well, you've already deleted all your manufacturers, and now you have no way to fetch new ones, for who knows how long. Much better to go on with a slightly outdated manufacturer list than none at all.
The deletion step could fail as wellfor example, if users had one or more records locked. If this happens and you don't catch it, you end up with duplicate manufacturers, which could be a serious problem.
The right way to do this is to perform the import first. If and only if it succeeds, you can then find the old records and delete them. The script should look like Listing 17.1.
Listing 17.1. Correct Import Script
Import Records [No dialog: http://my.mfg.com/mfg_update?code=3] If[ Get( LastError ) <> 0 ] Exit Script Else Show Omitted Only Delete All Records [No dialog] End If
This still isn't perfect, but it's much better. To make it better still, you'd need to examine what the exact error was during the import to decide whether some records had been imported and needed to be deleted. But it prevents the worst case, which is an empty manufacturer table.
For more on FileMaker's XML Import feature, which we posited as a possible source for the data in this example, see "XML Import: Understanding Web Services," p. 683.
It's easy to produce other examples of this kind. They all boil down to the same logical error: the unwarranted assumption that a specific step is going to work. The only time that it's okay to make this assumption is if there's no significant penalty for being wrong. For example, imagine you have a script that finds all invoices over 30 days old and changes their status from Current to Past Due. It's possible that the search will fail and find no records. But in that case it's innocuous to go on and perform the Replace stepit will operate on a found set of zero records and will have no effect.
So, one of the most important ways to avoid software defects (the graceful term for bugs) is to be aware of all the possible failure points in your system, and, most importantly, calculate the consequences of failure. Good programmers do this instinctively. They have a clear sense of what will happen if some element of their program fails. The question is never a surprise to them, and they almost always know the answer.
Part I: Getting Started with FileMaker 8
Using FileMaker Pro
Defining and Working with Fields
Working with Layouts
Part II: Developing Solutions with FileMaker
Relational Database Design
Working with Multiple Tables
Working with Relationships
Getting Started with Calculations
Getting Started with Scripting
Getting Started with Reporting
Part III: Developer Techniques
Developing for Multiuser Deployment
Advanced Interface Techniques
Advanced Calculation Techniques
Advanced Scripting Techniques
Advanced Portal Techniques
Debugging and Troubleshooting
Converting Systems from Previous Versions of FileMaker Pro
Part IV: Data Integration and Publishing
Importing Data into FileMaker Pro
Exporting Data from FileMaker
Instant Web Publishing
FileMaker and Web Services
Custom Web Publishing
Part V: Deploying a FileMaker Solution
Deploying and Extending FileMaker
FileMaker Server and Server Advanced
Documenting Your FileMaker Solutions