ELSE

Runs the ops nested underneath it when the branch directly above it did not run. ELSE has no test of its own. It takes the decision the preceding IF op already made and does the opposite.

Put it immediately after the IF op it belongs to, at the same level of the tree. When you need a second test before falling through, slot ELSIF condition THEN in between the two.

Fields

ELSE has no configuration form. Its Config tab carries the Name field every op has, followed by a YAML editor holding an empty document, because the op has no settings at all. Anything you type into that editor is saved onto the node and never read back.

The Options tab is cut down too. On an ELSE, and on every IF op, it offers Enabled and Debug Mode and nothing else. Return Key, the two rollback settings, Run Forward, Run Rollback, Parallel Mode, Error Handling and its trap settings, Timeout, Semaphore Key and Stage Name are not rendered at all. The next section explains what they would have done to the pairing.

Everything about how the op behaves comes from where you put it and what sits above it.

Placement

ELSE binds to the op directly above it at the same level of the tree. These are the ops it can follow:

• IF var THEN
• IF var ne value THEN
• IF var condition THEN
• IF var in LIST THEN
• IF condition THEN
• ELSIF condition THEN
• IF ANY nature THEN
• IF EXISTS nature THEN
• IF ANY bl THEN
• IF last trap action THEN
• IF ROLLBACK

Anything else above it, or nothing above it, and the rule refuses to run with a message naming the ELSE op and stating it is not after an IF block. That message arrives when the rule starts, not when execution reaches the op, so the whole rule dies rather than that one branch.

Ops you have unticked in the Enabled option are dropped before the pairing is worked out, so a disabled op parked between the IF and the ELSE is harmless. An enabled one is not, including a LOG Message you added while debugging.

Level matters as much as order. An ELSE that ended up as the first child inside the IF block, rather than as its sibling, has no IF above it at its own level and fails the same way.

One ELSE per chain, and it has to be last. A second ELSE right after the first has an ELSE above it rather than an IF, which is not accepted.

Why those options are hidden

Each of the hidden settings puts a wrapper around its op, and a wrapped IF is no longer adjacent to the ELSE that follows it.

A rule can still carry them, on a node built before the designer started hiding them or on one edited outside the designer, and then the rule refuses to start. On the preceding IF the settings that do it are Error Handling at anything other than Throw Errors, any Parallel Mode, Run Forward or Run Rollback unticked, a Needs Rollback Key paired with a Needs Rollback? mode, and a Sub Name. The message names the ELSE and says it comes after an IF in rollback, error trap or parallel mode.

The same settings on the ELSE op itself are rejected with a different message, saying an ELSE block cannot carry rollback, parallel mode or error trap wrappers. Timeout and Semaphore Key are the two the rule still accepts on either op, since neither wraps anything. The full list of these settings is in Rule Palette.

When you want an error trap around a branch, put it on an op inside the branch instead of on the IF or the ELSE.

What it does at run time

ELSE does not register itself as a step. Its name never shows in the job log and never reaches the monitor, however you rename it, and the cancel request that is checked at every other op is not checked here. Only the ops inside it show up.

It writes nothing into the stash.

An ELSE with nothing nested inside it is accepted and does nothing, which is a tidy way to say "and otherwise, carry on" without leaving a dangling test.

During a rollback pass the same rule runs again from the top with the rollback flag raised, and every condition is tested again against the stash as it stands at that moment. A run that took the IF branch going forward can take the ELSE branch coming back, because the values the IF looked at have changed since. Control which side executes in rollback with the Run Forward and Run Rollback options on the ops inside each branch, not on the ELSE.

Combining with other ops

Chain ELSIF condition THEN between the IF and the ELSE for a three-way or wider split. Each ELSIF is tested in tree order and the first one that holds wins, so the ELSE runs only when every test above it came back false.

IF var condition THEN is the IF to reach for first, since it compares stash values with no code at all. Pair it with ELSE and you have a two-sided branch with nothing written by hand.

Nest FAIL inside an ELSE to turn "the expected thing did not happen" into a job that stops with your own message.

Examples

Deploy approved topics, and record the skip otherwise.

IF var condition THEN
  When: All
    status   IN   approved,scheduled
  -> Deploy to environment
ELSE
  -> LOG Message   "skipped, topic status is ${status}"

Fall back to a default when a loader left nothing behind.

IF var condition THEN
  When: Any
    build_target   NOT EMPTY
  -> Run build
ELSE
  -> SET VAR   build_target = default
  -> Run build