Using ‘Exit Script ()’ at the end of a script - do or don’t?

Lounge (Discussions)
,
1

Most programming languages use brackets as code block delimiters. For scripts s a whole, FileMaker does not implement this concept.
I am using the ‘Exit Script ()’ step to mark the end of a script. Though technically not mandatory when no parameter is returned, it makes a script’s end explicit.

How do you handle script ends? What is your experience with the ‘Exit Script ()’ step as a script end statement?

2

Hi Torsten,

Interesting question :slightly_smiling_face:

I always use this step in my PSOS scripts as I read somewhere that it helps making sure the PSOS session ends after the script completes.

I don't really use it in client-side scripts except when I need to return a parameter. I don't think it's really useful as when I read scripts they're all individually contained in a tab or window, so I find they're clearly delimited by the interface and don't need an extra step.

Chloé

2 Likes
3

Something I'd want to call out here for anyone new to FMP scripting:

In the absence of an Exit Script step that explicitly sets a result value, Get( ScriptResult ) will return the value from the last time that the script stack executed a script which did include an Exit Script step that explicitly set a result value.

While no curly braces are required to do so, IMO, FMP scripting does incorporate code blocks:

  • The family of conditional script steps (If/Else If/Else/End If) delimit blocks of code
  • The Loop and End Loop delimit blocks of code
  • The separation of scripts from one another could also be seen as another form of delimiting blocks of code.

HTH & kind regards,

-steve

7 Likes
4

I end all scripts with an Exit Script for this same reason.

3 Likes
5

An important detail. Thank you @steve_ssh!

6

+1 for @steve_ssh's write-up. As a matter of coding standards we always explicitly set the exit status in order to not get bitten by the implicit behavior.

4 Likes
7

These days, I am trying to use as little code as required to get the job done...
Here is a script that I have in every File that does not end with an Exit Script step.
(I might even remove the comment on line 1 in some cases)
image

On the other hand, sometimes I will add an Exit Script step at the end of a Script just to hang a breakpoint on.

image

8

What happens when that script step fails? It can happen.

9

The script result persistence is a good reason to make mandatory exit script script steps for every script. This is something Claris could easily change (read: fix) in an upcoming release.

But it is not my main reason to use it because I'll basically check for script results immediately after a script where the result is set and will store the content in a variable. Attempting to read a result after a script that does not set one is likely to lead to some bugs.

Here is why I use it all the time:

  • Fundamentally all scripts should return a result. I may not have figured what it is yet, I may not use the result in the calling script, but scripts usually take an input and provide an output (even when the input is completely based on context and the output happens as edits to records). As such it can succeed or fail. So the step is there waiting for me, inviting me, nagging me, to provide the result. Some people go so far as describing scripts as functions, something that makes it clear they take inputs and provide outputs.
  • Of all the decisions we have to make, I do not want to spend any time 'figuring out' if I should use it or not. Think of it a bit like some people will wear similar clothing all the time because it is one less decision in their day. Rules like these let me focus on stuff that matters.
  • DEBUGGING: Sometimes I use the script debugger to navigate a sequence of scripts. Exit script is fairly neutral when compared to any other steps. If I drill down into a script and the last step is not neutral (set field, delete record, new record, go to layout, ... ) then I cannot set my debugging cursor on the last step and run that step to get out of the subscript.
  • DEBUGGING #2: If the last script step of the subscript is an end loop, then I cannot exit the subscript until the loop exit condition is met. This really makes me want to find the previous developer and have something unfortunate happen to him. You know what they say:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live
Who Said That One Violent Psychopath Quote? – Ruby and Rails (and stuff)

4 Likes
10

Like make them have to wear different clothing on different days. :innocent:

4 Likes
11

Precisely. You read my mind. :wink:

1 Like
12

in theory, we always add an 'exit script ()' with or without returm-parameter. Without param's, it helps debugging, keeping the debugger in that script (instead of exiting it and clearing variables)

There are always scripts, that miss the 'exit' - but thats a sign of being in a hurry (not good...)

1 Like
13

Heck, I have several scripts that are ONLY 'Exit Script'.

:rofl:

14

I routinely set an Exit Script [ ] step for this very reason; it greatly facilitates debugging. Also, with that step in place already it is easy to add a script result later if one is required.

4 Likes
15

Hi Keywords,

nice to see you in the soup !

2 Likes
16

+1.00

17

@jormond, using Exit Script( ) isn't sufficient unless you set a value. Is that what you are doing?

18

Yes. The easiest way to explain that usage looking at @weetbicks' Modal Magic article. That is the premise. I hadn't been using it quite that way, but this was a much simpler execution. The short version is that it sends back a value or indicator that the user has finished an action, and allows the main script to continue.

https://www.teamdf.com/blogs/modal-magic/

19

Huh! The @weetbicks modal magic is similar to a favourite technique of mine which works around the fact that we can't set a default time-out for custom dialogs.

I don't use exit script( ) at the end of every script. I prefer to take control of the process in a different way. I have a script which I use to set/clear the value of ScriptResult immediately prior to calling scripts that return a result.

# Name: ui_noop ( scriptresult ) 
# Purpose: Act as target for UI buttons
# Parameters: Optional. If provided the parameter will be used to set the value for Get( ScriptResult ) 

Exit Script [ Get ( ScriptParameter ) ]