`IfBlank` should allow three arguments (the third would be `if not blank do this`)

Suggestion Box
1

Sometimes a formula will try to access an attribute that doesn’t exist:

image
image764×94 9.48 KB

When this happens, it can wreak havoc on a series of in doc variables by turning them all into image error symbols.

Even attempts to manually override the behavior doesn’t fix the issue:

If(applicableManualResets.IsBlank(), false,  [...]  applicableManualReset.[Reset Time] [...])

Still results in a image symbol because applicableManualReset doesn’t have a [Reset Time] column right now, but it will once certain conditions are met (if Reset Time is > some value and < some other).

IfBlank can’t get around this with its current setup, but it could if it were given an additional argument allowing the user to specify what to do if the value is not blank.

E.g. in this case I could use it as:

applicableManualReset.IfBlank(false, [Reset Time])
Additional information.

Perhaps there is a way I could be structuring my formula differently to avoid this issue. If so, here is the full formula:

If(applicableManualResets.IsBlank(), false, 
applicableManualResets.FormulaMap(WithName(CurrentValue, applicableManualReset, 
  [Oldest Epoch In Occupancy] <= applicableManualReset.[Reset Time]
  AND CurrentCount.Epoch >= applicableManualReset.[Reset Time])).Contains(True())
)

And here is a screenshot of the error in action:

image
image864×344 51.6 KB

See also:

1 Like
2

I feel your pain, Connor, about this kind of error being “uncatchable” by the if statement. However, if I understand you correctly, I don’t think your proposed change to the IfBlank() formula is consistent with the existing formula. Right now,

var.IfBlank(false)

is equivalent to

If(IsBlank(var), false, yada)

only when yada is var. IfBlank is, in a sense, a special case of If, useful because it allows specifying a different “default” value other than Blank. Especially useful if var itself is a long formula.

I think what you really want is for your If() statement (and Switch) to stop looking for errors once the condition is met.

Or you want an IfError() formula, which I also think would be really handy.

3

Yeah, another way to say this is that

var.IfBlank(false)

is the same as

If(var.IsBlank(), false, var)

Right, a better way to solve this problem would be to have early terminating error checking . I.e. this formula should not throw an error:

If(
  variable.isBlank(),
  false,
  variable.attributeThatOnlyExistsWhenVariableIsNotBlank
)

However, it does currently throw an error.

Frankly, I’m not a fan of error catching nor exception handling. In object oriented languages I think it’s fine, but Coda is quite functional, so I think it’s better to stick with good old fashioned writing code that works and testing edge cases.

Edit: Let me clarify this. I really appreciate the errors the formula typechecking system gives me. That’s not what I’m trying to avoid. What I don’t want to have to do is Python style try...except blocks, nor IfError('ErrorType', ...)type code. I have found (for me at least) it leads to lazy and occasionally error prone code.

Made a new suggestion based on this conversation:

2 Likes