Bug in the Propa-Gator module - and maybe (all) others - and solution proposal

[Russell Watson]

Hi folks,

Thanks for accepting me into the group :) and thumbs up for Modular FileMaker - great concept! Thumbs down and death be to all (unnecessary) dependencies!

(more praise, more praise, more praise…however...)

I've found a programming bug in the Propa-Gator module that you may wish to clear up - and, because it seems to be an error in the script parameter parsing code it may well be in all modules.

"An error in the script parameter parsing code?" I hear you say? "No way! It has been tried and tested 1000 times."

Indeed - and the parsing code is great - no problem there, … yet nevertheless a pervasive bug has … or will … slither into the code and bite you.

It is a good old FileMaker Gotcha that has got you this time!

It is none less than the Get( ScriptResult ) problem (you know it already?) caused by multiple script-exit-strategies in the script, some which return a parameter, and some that don't.

The script in the pic, CreateRecord, looks as if it is designed to return an error value, that you can check in the calling script to see if everything worked. - Nice. Like it.

….HOWEVER … should the calling script have managed to botch its parameter-passing, this will cause a parsing error and the CreateRecord script exits (at line 14) WITH NO RESULT PARAMETER. This, as you probably know, causes FileMaker to NOT SET the Get( ScriptResult ) value (one of those Very Strange FileMakery Behaviours that make us love and hate our tool the way we do), which in turn means the attempted check of the ScriptResult in the calling script ACTUALLY returns the result of the PREVIOUS (successful) SCRIPT CALL - what, where and whenever that may have been.

In other words after returning from this (or any such) script the Get( ScriptResult ) function in the calling script is USELESS*.

Thanks for the cool stuff again, and I hope this helps to catch the bug before it bites too many poor innocent unsuspecting developers. :-)

Greetings from Germany

Russell Watson (aka MrWatson)

* Well, not quite: You *could* call a script which always returns an empty string before calling the CreateRecord script….but in the long run it'll probably lead to better, more readable code if you (Proposal 1:) define a standard result/error code that can be returned when the parameter parsing fails.**

** (Proposal 2:) HOWEVER, if a script returns NO ScriptResult, then the exit-on-parsing-error should also return NO ScriptResult***

*** (Proposal 3:) This tricky reality of FileMaker programming needs to be communicated to users of mFileMaker

P.S. If you like the script colors and line numbers in the script editor pic, note it is NOT an illustrator touch up job,Line but the real thing in the FileMaker Script Editor - just:

1. Get a mac

2. Get the MBS Plugin from monkeybread software 

3. Get the cool tool fmSyntaxColorizer (or its big brother fmWorkMate) from www.fmworkmate.com (i.e. from me)

then

4. start fmSyntaxColorizer

5. and press [colorize!]

It's free too. :-)

[jeremy...@gmail.com]

Perren Smith pointed out to me a solution to this problem, which I'll submit as Proposal 4: all Exit Script steps that do not have a result to return should have the empty string "" explicitly set as the result to return. This does clear out the any lingering result from Get ( ScriptResult ) in the calling script.

[Corn Walker]

And this is why I say exit once, and only once, in a script and make sure that script returns an error code, even if the result is to indicate there was no error.

[jeremy...@gmail.com]

When it rains, it pours! This is twice in one day I get to complain about the single exit point non-rule. I can agree on the error code return value for scripts that will accommodate it. (Pre-event trigger scripts have other plans for their return values dictated to us, so they are exempt.) The single exit point guideline is a well-hashed debate already. I personally don't find it to be a constructive restriction. The single exit point non-rule is the don't-end-a-sentence-with-a-preposition of programming: it's only a rule if your boss says it is.

[Corn Walker]

Never said it was a "rule" and don't wish to re-hash it here, other than to say when you have a practice that allows for multiple exit points you need to make sure to clean up after yourself at all of those exit points. For example, some have made a case that you should always restore User Abort State and Error Capture State when exiting your script (in addition to exiting with a return value). If you have five exit points in your script, that's five places where you should restore these values.

So exit once and take care of it all there, or exit five times and make sure you do it in all (three? five? eleventeen?) places. I think this bug illustrates how much more vigilant you have to be about exiting cleanly when you do it in more than one location, and that is enough to tip the balance in favor of exiting once in my experience.

[jeremy...@gmail.com]

I agree that care needs to be taken for appropriate clean up with any number of exit points, but I rarely see a script with multiple exit points where each of the exit points calls for the same clean-up. Some refactoring would be in order in that case, usually breaking the behaviors out into smaller subscripts. In the particular case of User Abort and Error Capture states, my own opinion is that these should be restored immediately after the script steps that required them, not waiting until exiting the script.

[Daniel Smith]

I think the best way to define/resolve the Get ( ScriptResult ) issue is:

If a script ever returns a result, it must always return a result; even if that result is an empty string.

This differs from Perren Smith's proposal in that it allows a script to never return a result. A valid use case (in my opinion) for a script that never returns a result can be found in my PluginManager module: http://www.modularfilemaker.org/module/pluginmanager/ in the "PluginManager: Config: Go To Layout" script. It contains a single Go To Layout script step with no error checking. The calling script can check Get ( LastError ) to see if the Go To Layout step succeeded/failed.

--
You received this message because you are subscribed to the Google Groups "Modular FileMaker" group.
To unsubscribe from this group and stop receiving emails from it, send an email to modular-filema...@googlegroups.com.
To post to this group, send email to modular-...@googlegroups.com.
Visit this group at http://groups.google.com/group/modular-filemaker.

To view this discussion on the web visit https://groups.google.com/d/msgid/modular-filemaker/561d1cc5-7221-4601-9ef9-c93ee521eec8%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel Smith]

I just noticed a somewhat similar issue which affects version 0.2.0 of my PluginManager module. If the last step in a sub-script returns an error, then Get ( LastError ) will return that error code in the calling script. The reason this is an issue for me is that I always check Get ( LastError ) after calling a sub-script. My assumption has been that if an error occurred, then the script was not run, likely because the user does not have permissions or it was deleted. Because of this, I usually abort the current script.

The reason this is a bug in my PluginManager module is because the last step in most of my scripts is to call a module-level "Config: Create Log Entry" script, which the user can modify as necessary to create log entries. So, if you were to modify that "Config: Create Log Entry" script so it's last step returned an error, that error would propagate up through multiple calling scripts and the final error message would say something miss-leading like "this module script could not be run, probably because the user does not have permission, or a script has been deleted."

The (currently unpublished) fix I have for this issue is to add a Set Variable step right before exiting any sub-script, which just set's $! to a null value. This step will cause Get ( LastError ) to return 0, which ensures that the last error isn't propagated to calling scripts, when I don't want it to be.

To re-cap; if you test Get ( LastError ) after performing a script, this issue affects you. The fix is to add a script step that you know won't return an error.