# Scripting: If Statements and Exit Script
**URL:** https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200
**Category:** Lounge (Discussions)
**Tags:** scripting, optimization
**Created:** [June 7, 2021, 1:08am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200 "2021-06-07T01:08:23Z")
**Posts on this page:** 9
**Page:** 1
### Author:  [@steverichter](https://the.fmsoup.org/u/steverichter)
#### Post date: [June 7, 2021, 1:08am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/1 "2021-06-07T01:08:23Z")
I typically create scripts with the structure:
Enter Find Mode
Set Field
Set Field
Set Field
Perform Find
If Get Found Count \> 0
Do Stuff
Else
Show Custom Dialog - No Results
End If
Exit Script
However, I’ve seen another structure:
Enter Find Mode
Set Field
Set Field
Set Field
Perform Find
If Get Found Count = 0
Show Custom Dialog - No Results
Exit Script
End If
Do Stuff
Exit Script
While I like the logic flow of the first method, the second may be easier to read. What is your preferred method?
---
### Author:  [@Malcolm](https://the.fmsoup.org/u/Malcolm)
#### Post date: [June 7, 2021, 2:08am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/2 "2021-06-07T02:08:15Z")
The second structure you've described is sometimes called a guard clause. It's used to ensure that code is not run unnecessarily. They can improve readability in several ways. You've shown one way, which is that if the preconditions for the remaining code are not met then the script stops. It is also self-documenting ( not taking the place of documentation but it makes itself clear ) in that you can see immediately that the code will handle the "nothing found" case and how it handles it.
Another reason I like it is that it keeps the code simpler. When you nest code within multiple IF statements it is possible to lose track of which lF an ELSE refers to. Guard clauses flatten the code by reducing the amount of nesting.
---
### Author:  [@steverichter](https://the.fmsoup.org/u/steverichter)
#### Post date: [June 7, 2021, 2:58am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/3 "2021-06-07T02:58:57Z")
> [@Malcolm](#):
>
> When you nest code within multiple IF statements it is possible to lose track
Yes, I’m considering switching to this format to reduce the indenting a bit. Thanks for the info.
---
### Author:  [@planteg](https://the.fmsoup.org/u/planteg)
#### Post date: [June 7, 2021, 3:22am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/4 "2021-06-07T03:22:25Z")
The first form has this disadvantage: if the code to be executed is quite long, then to find the else code forces the developer to scroll down to the bottom of the script.
With the the second form, the 'else' is right at the beginning, then the long code is after.
---
### Author:  [@steverichter](https://the.fmsoup.org/u/steverichter)
#### Post date: [June 7, 2021, 3:29am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/5 "2021-06-07T03:29:05Z")
> [@planteg](#):
>
> With the the second form, the 'else' is right at the beginning
Thanks, I’ll experiment with a guard clause on my next script.
---
### Author:  [@daleallyn](https://the.fmsoup.org/u/daleallyn)
#### Post date: [June 7, 2021, 3:29am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/6 "2021-06-07T03:29:31Z")
You're received great replies, but I'll just add a voice to preferring the second structure as well, for the reasons mentioned (mostly exiting ASAP). Cheers
---
### Author:  [@bdbd](https://the.fmsoup.org/u/bdbd)
#### Post date: [June 7, 2021, 3:19pm UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/7 "2021-06-07T15:19:05Z")
I am not a fan of guard clauses, however I use a variation of the second. I substitute the exit clause with an else clause. My logic goes this way: write the if condition such that errors are processed at the start because they are usually short code blocks. I find this enhances readability.
---
### Author:  [@FileKraft](https://the.fmsoup.org/u/FileKraft)
#### Post date: [June 7, 2021, 9:02pm UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/8 "2021-06-07T21:02:57Z")
I mostly use only one Exit in a script except if it is a script trigger before the event - even then it is possible to keep one exit using a calc for the result.
---
### Author:  [@jwilling](https://the.fmsoup.org/u/jwilling)
#### Post date: [June 8, 2021, 12:09am UTC](https://the.fmsoup.org/t/scripting-if-statements-and-exit-script/2200/9 "2021-06-08T00:09:34Z")
I'm a big fan of the single-pass Loop as a way to break out of a script early, while still having only one exit script line:
```python
Loop
# single-pass loop
Enter Find Mode
Set Field
Perform Find
# The calc below assumes a CFs called Error() and ErrorFound() exist
Exit Loop If [Let ( $error = Error ( Get(LastError) ; "Perform Find" ) ; ErrorFound($error) )]
# Do Stuff
# end single-pass loop
Exit Loop If [True]
End Loop
If [ErrorFound ( $error )]
# Handle error here. Show dialog? Log error? Revert Transaction?
End If
Exit Script [JSONSetElement ( "{}" ; [ "error" ; $error ; JSONObject] ) ]
```
One huge benefit is that this is a generalized strategy for breaking early that works with any type of "error" or any condition you consider an error/exit-worthy. So you could also add error traps after `Enter Find Mode`, and `Set Field` to catch unexpected errors like a trigger canceling the layout mode change and privilege restrictions preventing the user from setting that search field.
It also lets you centralize the error handling and Exit Script, so if you have a long-ish procedure for handling errors, you only have to put it in one location.
_EDIT: I really wish Claris would give us Try/Catch so that you could passively trap for Get(LastError) without having to explicitly poll for it after each script step. My scripts would be half as long_