Formula Checking: Don't Catch Errors that Cannot Happen

When checking whether a formula has errors, only throw Unexpected dot operator error if that line can be logically reached.

Right now, when you write the formula:


If variable is blank it displays this error:

I want it to return false.

You can play with it here: Error Handling

This matters because there are scenarios where you have a variable that is normally not blank and is used in a subsequent calculation. If it is ever left blank and a formula tries to access its attribute you will end up with an error that bricks the rest of the formulas that rely on this variable.

The price to pay will be that formulas written inside If() and Switch() statements won’t be able to tell you ahead of time whether they reference a non-existent attribute. However, formula chips should help you to get around this shortcoming.

Originally, I explored this in a very misguided suggestion to add a third argument to IfBlank. Thanks to @Ryan_Martens2 for pointing out that I was wrong and for pointing to this as the better solution.

1 Like

Any codan on this? Seems almost a bug and in our case makes several correctly working formulas return errors instead of messages to users.

@Connor_McCormick et al

one of the best practices that I advocate for is to avoid using named canvas formulas as intermediary variables and use a single-row table for these instead.


  • Canvas formulas don’t have type affinity, and table columns do. The issue in this thread is exactly this: variable.[Column] is invalid because Coda cannot infer that variable is a row/list-of-rows from a the table when it’s given a Blank value. There’s nothing to take that info from. Meanwhile in a table, the fact that the column has type affinity of “Lookup from table X” actually lets Coda assume that in case of no value, it should still treat that cell as of type “row/list-of-rows from table X” and not report an error on attempted dereference.

  • Besides, Coda actually creates a single-cell table behind each formula anyway.

  • Also you’re saving on objects count if you’re on free plan. But most important, of course, is bullet #1


P.S. It’s not the “error that cannot happen”; Coda does not (and should not IMO) analyze that deep into the dependency tree. I’d argue that it should work with variable.[Column] at all given that there’s no information about variable's type. But I guess they were trying to make it work “in the most commonly expected way” for regular users, so it attempts to infer the type when the value is actually something.


Ah, very interesting.

It’s surprising to me that a single-row table is lower object count than a selector.

Should the title of this post be changed to: “Don’t infer the variable type if the variable is blank”?

@Paul_Danyliuk, following up on this