Validation - simple or extreme?

[AndyHibbs]

It has been a little quiet in ‘the soup’ over the last couple of days, so a job we’re towards the end of has lead to this question for a bit of discussion.

The project is an integration from a multi-file design from the 1990s into our SaleFaith structure. All validation in our current systems is scripted, as are the majority of calculations, summary fields, etc, but the old files rely on unstored calculations, field level validation and many other techniques that have been replaced by features from newer versions of FileMaker (I’m not suggesting calculations and field level validation shouldn’t be used, they just aren’t by us).

To my point. I was caught out by entering Find Mode, because a field from an old table we’ve imported for data migration failed validation, which lead me to wonder whether people are error trapping for every eventuality that something like a validation failure can cause.

For anyone not on my wavelength; when using field level validation with Error Capture set to ‘On’ every instance of ‘Go To Layout’, ‘Enter Find Mode’, ‘Go To Related Records’, ‘Go To Record’ and no doubt many more I’ve not listed can prevent actually leaving the current record.

The worst example: an instruction to leave the current record using one of the above methods, validation prevents this, and the next scripted instruction is ‘Delete All Records’.

Finally to my question. Does everyone error trap for every instance in every script for all of the aforementioned leave record script steps? My belief is, that if you use field level validation, then absolutely you should, otherwise pain is inevitable in the future.

I do acknowledge that field level validation and protection is the most secure method of protecting data and enforcing rules, but don’t want to get into that here now, as it will distract from the above question.

Regards
Andy

[AndyHibbs]

Oops, just thought of a few more, ‘Close Window’, ‘Close File’, ‘Enter Browse Mode’, ‘Commit Record’ (of course)’ ‘View as Table’, ‘View as List’

[Torsten]

In my solutions, field level validation is only used for fields filled in by script. Users cannot alter those fields. For fields modifiable by users, validation (if required) is triggered at the time of entry (i.e. On Modify). For the scripted fields there is no error-trapping (validation of field entries is part of the script validation process).

[AndyHibbs]

Torsten, I like the validation of field entries being part of the script validation process. This should remove any need for error trapping, but woe betide you if you don’t sync every validated field with every script.

[Torsten]

Well said, @AndyHibbs. The margin for errors is small, going this way. Until now, this worked quite well for me. Prerequisite is a thorough test plan

[AndyHibbs]

While I think of it, the script validation is why we keep repeating that we need an ‘OnRecordExit’ or ‘OnRecordUnload’ trigger. Doing this using ‘OnRecordCommit’ is too intrusive during data entry.

[Torsten]

I fully agree with your assessment. The 'OnRecordExit' Trigger is missing. Work-arounds can be done based on 'OnWindowClose' and 'OnLayoutExit', but this requires extra logic and has its own pitfalls.

[tonywhitelive]

Error capture management and field level validation are 2 of the more complicated and important areas in the Filemaker platform. Put them together in a story and you have started an interesting conversation.

Here are some thoughts…

1. I like to set error capture to On only when I know what errors I am capturing and handling.

I do not know every possible error that might happen. Therefore, I prefer to “see" errors that I do not know about so that I can add them to my understanding and coding patterns as they come up.

Rather than turning error capture on at the top a script, we will turn it ON before a script step that we know might throw an error and turn it back OFF after.

2. ErrorCaptureState, as revealed by the (Get) ErrorCaptureState function, is an attribute of the Script Call Stack. This means that ErrorCaptureState changes caused by Setting ErrorCapture ON or OFF can be passed from Script to Script and/or from File to File.

This can make determining the ErrorCaptureState that a Script is running under hard to read. One solution is to have the same number or Setting ErrorCapture ON or OFF script steps within each Script, with the default being OFF. In other words, for each time we set ErrorCapture ON in a Script, we also set it to OFF.

3. One of the subscripts that that we perform at the top of many scripts, commits that record and Halts if there are any errors. This catches failed fields validations. That said, there are, as you have mentioned, lots of manual actions that users can take that can cause the issues that you have described.

While there is more to say on all this, I will stop here for now.

Good topic(s).

[jwilling]

@AndyHibbs

Finally to my question. Does everyone error trap for every instance in every script for all of the aforementioned leave record script steps? My belief is, that if you use field level validation, then absolutely you should, otherwise pain is inevitable in the future.

I check for errors after everything that can cause one. We use a single-pass loop to simulate a "try-catch" script block. When an unexpected error occurs within that block, we set an $error variable with an error object (usually JSON, but sometimes Let-notation depending on the app), exit the single-pass loop and handle the error in a centralized location at the end of the script. We also pass the $error object to the calling script so that it can respond appropriately as well.

We also have a hosted Log.fmp12 file where we log any errors that occur, along with additional info about context, privileges, account, device etc... so that we can review what went wrong and where without having to bug the user to walk us through their process. Logging is handled in the "Handle error" section at the end of the script, outside of the single-pass loop.

I'm a huge advocate for obsessive, 100%-coverage error trapping and detailed error logging. It helps catch bugs early and makes troubleshooting bugs later much faster. It also makes developers more confident when making changes because they know that if they break something, the error trapping will detect it and log the issue. It takes the pressure off you to remember everything about the system, and instead, the system itself tells you when something is wrong. Such peace of mind.

[bdbd]

I am with @jwilling on this one: check for errors in scripts, whether you expect one or not.

Considering FileMaker is a context-based environment, one should always ensure that the desired context exists either before an important action occurs (delete all records, for example) or after certain actions occurred (go to layout, for example). Which you use and when is implementation-dependent.

[Malcolm]

Context is everything isn't it?

My scripts are littered with guard clauses to ensure that they will not run unless they are in the correct context.

[AndyHibbs]

Thanks Tony and Josh

First things, I’d like to thank @jwilling for his Visual Studio Code extension that @ajmchambers brought to my attention this week. Brilliant!

Interesting approaches we take, which I suspect are at times quite different but with frequent convergence. Unlike Tony, we tend to set Error Capture on at the start of just about every (non-called) script. Neither is right or wrong.

I believe there are 2 types of error trapping, one for debugging and the other for user interaction. The first requires the error message to be known, whereas the latter can normally be accommodated by ‘Get ( LastError ) <> 0’ and appropriate progress from there.

There are also times we capture the error, turn error capture off, repeat the process that created the error, so that the user will receive FileMaker’s own message - record locking being the one that jumps immediately to mind due to Error Capture Off displaying the name of the owner of the record, which is suppressed by it being set to on (there is a ‘please’ in there Claris). We also ‘bundle’ recorded errors and report at an appropriate time when appropriate.

It looks as if we have a consensus that, regardless of implementation, trap for everything. I wonder how many reading do so? Example code would be Commit Records-> Error Trap -> Go To Layout - Error Trap -> Enter Find Mode - Error Trap - Perform Find -> Error Trap - Go to Record - Error Trap.

This is certainly the difference between ‘new’ FileMaker and ‘old’ FileMaker. The days of forms and lists only, navigate using the layout menu and have users popping into layout mode to add some text for a merge letter are pretty much behind us. We’re app developers now and spend more time trying to work out how our routines can be broken than making them work in the first place. The perception of developing in FileMaker needs to change a lot as a result.

I personally feel much more comfortable keeping the ‘intellect’ of the system within scripts, where everything is in one place, is traceable and more controllable, than the ‘wildcard’ of having to consider other factors. Again, I would appreciate keeping the security aspect of this out of this thread, it would make a great subject for another one.

Thanks for everyone’s input so far and I look forward to further contributions.

Regards
Andy

[ByteTheBullet]

While I've tried in the past to error trap for any issue, I know there have been cases where we've had unexpected results. Nowadays, I too am moving towards a single-pass loop, with error trapping after every chance were an error can occur. And we stick to steps after an error is caught where the error stays in the stack (ie: can be retrieved by Get(LastError) if it was indeed a FileMaker-aware error. If it's an error due to business logic, it gets saved in a json object and passed back to the calling script(s) to handle.