• Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint
Share this Page URL
Help

Chapter 17. Troubleshooting > Planning for Trouble

Planning for Trouble

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 (naïve) script:


PREVIEW

                                                                          

Not a subscriber?

Start A Free Trial


  
  • Creative Edge
  • Create BookmarkCreate Bookmark
  • Create Note or TagCreate Note or Tag
  • PrintPrint