# Replacement for "If Prev Action Failed"

**URL:** https://www.finalbuilder.com/forums/t/replacement-for-if-prev-action-failed/3829
**Category:** Feature Requests
**Created:** [February 9, 2007, 6:23am UTC](https://www.finalbuilder.com/forums/t/replacement-for-if-prev-action-failed/3829 "2007-02-09T06:23:45Z")
**Posts on this page:** 1
**Page:** 1

<div class="post-metadata">

### Author: ![stevage](https://www.finalbuilder.com/forums/letter_avatar_proxy/v4/letter/s/bc8723/32.png) [@stevage](https://www.finalbuilder.com/forums/u/stevage)
#### Post date: [February 9, 2007, 6:23am UTC](https://www.finalbuilder.com/forums/t/replacement-for-if-prev-action-failed/3829/1 "2007-02-09T06:23:45Z")

</div>

It seems to me that the hierarchical structure of an FB scrpt is underused. Currently the relationship parent-child basically means “if parent succeeds, run child”. But so does sibling1-sibling2. And there are lots of times when you want to run the child if the parent _fails_. And yet “If Prev Action Failed” just looks and feels ugly and wrong - especially since it only works if “Ignore failure” is ticked. “Ignore failure” is blatantly misleading when you’re about to take action if it fails.  
  
So, my proposal: Create two new action types, one called “Success” and one called “Failure”. The first runs if its parent succeeds. The other runs only if its parent fails - regardless of the “Ignore failure” setting. This would let you set up very readable trees like this:  
  
Compile program  
-Success  
–Zip up result  
–Write “success” to text file  
-Failure  
–Write “error compiling” to text file  
Compile next program  
  
Advantages of the above:  
- No misleading “Ignore failure” - build would automatically stop after the “Write error compiling” action  
- (related) No “Error ignored” in the log  
- Totally self contained - the “Compile program” node contains all behaviour related to that action, without needing siblings (If Prev Action Failed) or parents (Try/Catch).  
- Very readable  
- Almost always syntactically valid (unlike try/catch/endtry). The only bad combinations would be success or failure as top-level nodes, or perhaps one directly under the other, which is just meaningless.  
  
Users could also then have a choice of what the default behaviour of a parent-child link is: success or failure. Either way you could override it with an explicit Success or Failure action.  
  
Steve