Error Trapping

[T-Square]

I will preface this by saying I believe that the answer to the problem outlined below will be: "Look at your scripts closely and decide where to do error testing." I am hoping that someone else will have figured out an elegant, easy alternative to this, and will share their experience!

I am in the midst of re-thinking how I handle errors that arise in the course of my scripts, and I am looking at ways of creating a generic error routine.

What I envision is a system where I have:

* errors stored in a separate table,

* a global field for the current error, and

* a layout to display the current error to

the user when an error situation arises.

I already have this functionality in place (I loaded the list of error codes from Filemaker's Help, and added application-specific codes of my own), but I am left with the dilemma of determining when to test for an error status. Certain script steps are obvious: after performing a search, or after changing a data record in a script. But there are seemingly an infinite number of ways to create errors. Aside from testing for errors every other line of my scripts, does anyone have recommendations on how best to proceed? Is there some general means for triggering a custom error routine? Are there a particular set of script steps after which you should always test for errors?

Cheers,

David

[Wim Decorte]

When you should trap for error depends on the business process your scripts are solving. Whenever data is created or modified or supposed to be deleted you definitely need to trap for errors. Probably printing too although that may not be necessary.

[T-Square]

What I was hoping for was a list of common situations/script steps after which one should test for errors. As I think about it, it all really boils down to checking after any explicit or implicit changes to the database content. The trick is to figure out all the circumstances in which this occurs. Obviously, after any Commit Record, Replace Contents, Delete Record, or Import Record steps.

However, it would also seem to be necessary to check before a change in context (for example, Go To Layout, New Window, or Go To Related Record)(and others?), as there is an implied Commit Record when one goes to another layout. [Does this implicit commit occur when one changes from one layout to another based on the same Table Occurence?]. In addition, it is presumably necessary before a change in Mode (Browse vs. Print vs. Find modes), for the same reason.

Filemaker's new record management paradigm suggests to me that before invoking any of these script steps, records should be explicitly committed and tested for errors.