Errors occurring when specific script steps fail

[brian rich]

I'm reviewing my somewhat limited error handling procedures so I can code to handle various possibilities in a better way. I need to know when I should be looking for errors, and when they do occur, what to do.

Which script steps generate error codes and is there a list of error codes that can be related to a specific script step?

- For example if a New Record step fails, what error codes should I expect to see?

- Does the go to next field step generate any error codes and if so, what would they be?

I can't find a list; maybe I'm not asking Filemaker's Knowledge base or Google the right question.

Can anyone help?

Brian

[bcooney]

Error codes are listed in FM Help. However, you don't necessarily need to trap explicitely. You can simply:

Script Step

If Get (LastError ) ≠ 0

//Do error handling steps here

Else

//success, continue

End If

[jbante]

You can find a list of FileMaker error codes here: http://www.filemaker...rror_codes.html

As far as I know, there isn't a comprehensive list anywhere of which script steps generate which errors. Most of that knowledge comes from experience, but you can guess which codes might be generated by what script steps based on the error descriptions. Further, just because FileMaker threw an error code doesn't mean there was really an error. For example, the Go to Record/Request/Page [Next; Exit after Last] step will throw an error (101 - Record is missing) when you call it from the last record in a found set, but that doesn't mean anything is broken. Also, FileMaker can't tell you when there's a logic error, such as when I write a script that creates a New Record when I'm on the wrong layout.

In my experience, trying to anticipate and handle all possible errors in every situation is not worth the effort. Testing (LOTS of testing) and experience will tell you what errors to handle, and what errors you can ignore.

You may find some useful nuggets from the discussion on FileMakerStandards.org: http://filemakerstan.../Error+Handling

[Lee Smith]

Have you tried using Script Debugger and Data Viewer to follow what the Scripts are doing?

[brian rich]

@bcooney:

It's the bit about "//Do error handling steps here" in your pseudo-code that I was hoping could be better structured

@Jeremy bante:

It was actually your discussions thread about error handling on filemakerstandards.org that got me thinking about this. I've got to a point where I've got some standard custom functions and scripts I can use to manage the error handling in a consistent way. I was then moving on to the issue of resolving the problem. Having a list of the possibilities seemed to be a useful way of determining whether resolution was possible or not.

New record on the wrong layout - who, me? (I don't think I'll add an error handler for developer errors - I fear for the size of the log file!)

@ Lee Smith

I use the error code reports and pause on error frequently. It could help if I was able to set up a test situation to see what errors can occur, but it would take an age to set up.

[bcooney]

I don't see how you could come up with a one-size-fits all solution for what you do if there's an error. It seems to me that it would be very much tied to what failed (and not just New Record) but the process.

Of course, this all ties in with transactional scripting.

[Vaughan]

Looking at it pessimistically, ANY and ALL steps could fail. Even the humble and reliable Go to Layout could fail if is being edited at the time the call is made.

The trick is to work out which steps are critical. I always trap for errors opening records for editing, creating new records, committing records, and the GTRR step to ensure related records actually exist. Where necessary I trap for record delete errors too.

I ask myself "what would happen if this step failed" and consider this against the risk of that failure happening, and the magnitude of the consequences. Errors creating new records and validation errors on commit are high. Edit errors from record locking are a certainty -- it WILL happen one day.

Consider this code:

Go to related records [ relationship ; current record ]

delete found records [ no dialog ]

go to layout [ original ]

This is a problem because if the current record has no related records then the WHOLE DATABASE will be deleted by the second step.

This could be changed to:

If [ not isempty( relationship::foreignkey ) ]

Go to related records [ relationship ; current record ]

delete found records [ no dialog ]

go to layout [ original ]

End If

... or...

Set Error Capture [ on ]

Go to related records [ relationship ; current record ]

Set Variable [ $error ; Get( lastError ) ]

Set Error Capture [ off ]

If [ $error = 0 ]

delete found records [ no dialog ]

End If

go to layout [ original ]

[Fitch]

FWIW I tend to use the "If [ not isempty( relationship::foreignkey ) ]" type of scripting (avoid the error).

I have seen some solutions where the scripts were super modularized: mostly short, single-task scripts such as create or delete a record, and then the script would exit with the last error. Then other scripts would call these single-taskers something like:

Perform Script( delete record )

Set Variable( $error ; Get(ScriptResult) )

If( $error = 0 )

  // proceed with whatever

End If

This "If( $error = 0 )" was in literally every script, sometimes multiple times. Once I got used to it, I found it very nice clean code to work with. I would recommend this approach if you want to be extra-vigilant in your error trapping.

[Vaughan]

FWIW I tend to use the "If [ not isempty( relationship::foreignkey ) ]" type of scripting (avoid the error).

There is a possible race condition here. It's unlikely, but possible, that if there is a single related record and it gets deleted between the steps the error goes un-trapped.

[brian rich]

@bcooney:

I don't see how you could come up with a one-size-fits all solution for what you do if there's an error. It seems to me that it would be very much tied to what failed (and not just New Record) but the process.

@vaughan:

The trick is to work out which steps are critical. I always trap for errors opening records for editing, creating new records, committing records, and the GTRR step to ensure related records actually exist. Where necessary I trap for record delete errors too.

Filemaker must know what errors can occur with each script step. Take this snip from the Filemaker Help on Go To Related Record

If you select a table occurrence to which there’s no relationship, or a layout that doesn’t refer to the correct table occurrence, FileMaker Pro displays an error message. After the error message displays, script execution continues with the next script step.

Why don't they say which error message(s)?

I'm guessing that the relationship errors might be codes 100 - file is missing or 107 - table is missing.

The layout errors might be 414 - Layout cannot display the result or 1209 - Name is missing.

If it was one of these, I wouldn't want to continue

Does the GTRR step ever generate an error 101- record is missing when there is no relationship? Error 101 is not significant when I execute a go to next record step on the last record in the found set, and I would be happy to ignore it. In the GTRR situation, I simply don't know.

If you don't have the knowledge of how a script step can fail, you are forced to trap errors tactically rather than logically. That doesn't seem like a reliable approach to me. If I know explicitly what errors can occur, I can handle these in my error handling code in an appropriate way.

Brian

[Vaughan]

Filemaker must know what errors can occur with each script step. Take this snip from the Filemaker Help on Go To Related Record

--

If you select a table occurrence to which there’s no relationship, or a layout that doesn’t refer to the correct table occurrence, FileMaker Pro displays an error message. After the error message displays, script execution continues with the next script step.

--

Why don't they say which error message(s)?

Easy enough to find out: perform a practical test.

But that isn't the kind of error you need to trap for. Missing layouts or relationships are "mistakes" caused by the developer. You need to be trapping for "normal running of the program" errors such as record locking, empty found sets, empty find criteria, and so on.

Usually with most error trapping it's sufficient to simply trap for error ≠ 0. It often does not matter what the error is, just that there has been an error.

The kind of errors you need to know with GTRR are what happens if there are no related records, in particular if the GTRR step has the option to make a new window: if there are no related records the new window does NOT get created, but the step changes to the specified layout and selects all records in the related table.

[brian rich]

Easy enough to find out: perform a practical test.

But that isn't the kind of error you need to trap for. Missing layouts or relationships are "mistakes" caused by the developer. You need to be trapping for "normal running of the program" errors such as record locking, empty found sets, empty find criteria, and so on.

Here's a couple of rhetorical questions:

How many possible test conditions are there where there is 'no relationship' in a GTRR?

It's also possible that the related table is in a separate file which is off line for some reason. Does that generate a relationship error message, a layout error message or a file is missing error?

I fully understand about your tactical approach to error trapping for what you 'expect' to happen; I've been using that approach with FMP development for a while and yes, it works well, until suddenly one day it doesn't and you have to find out why.

I just thought that it would be nice to know all the possibilities before the event rather than knowing only some of them by accident afterwards.

Brian

[Fitch]

There is a possible race condition here. It's unlikely, but possible, that if there is a single related record and it gets deleted between the steps the error goes un-trapped.

Good point!

[LaRetta]

I just thought that it would be nice to know all the possibilities before the event rather than knowing only some of them by accident afterwards.

Spot on, Brian, and I have spent quite a bit of time researching as well. I will let this thread speak for me about it ...

http://fmforums.com/forum/topic/61303-error-disadvantages/page__hl__%22error+code%22__fromsearch__1