Currently in Tulip, when an expression contains a null variable or record placeholder not surrounded by LINK(), the whole expression turns into null. While this is in itself possibly questionable, let’s assume we’ll keep it this way for now.
The issue I see with the current situation is that this happens silently. From my experience, customers have often lost a lot of time looking for that kind of error (especially when the “nulled” expression is printed on a label, in which case no label is printed, which made them look for printed-related issues…).
It would be much better for them to be warned about this right when it happens. While using LINK() helps a bit with this situation, it is much less visible than an error message.
I suggest that in such a case, a red error message is displayed and, most importantly, that more information is given about what happened. For example: Expression error on step ‘My step’: variable ‘My variable’ is null.
(Ideally, it would be great to also have the expression context (trigger name, Enabled state condition…) but that’s probably harder to implement.)
I see your issue, but I disagree with the solution.
There are actually use cases, where you want to output a null value from an expression editor.
This is not necessarily an error.
You can make use of variables being null. If you want to avoid null as outcome, you can give every variable a default value…
What I really would appreciate is, that the Variable preview in the Dev Mode (Test player) on the left hand side would differentiate between null and empty strings (e.g. an additional info with the string length that shows {null} if null and 0 if empty string).
This issue is a bug fixing topic in my opinion and not something to display in the operators front end view!
Or maybe it can be configurable.
If Tulip implement this proposal, they should also prepare an Account wise feature flag or expression wise toggle switch to activate/deactivate the error showing feature of the null evaluated expressions.
Handling null correctly is very difficult, so I guess new instances can have those error message feature activated by default.
I agree, that understanding null vs. '’ or 0 is difficult at the beginning and it is hard to spot, because it is hard to see/recognize.
In my opinion the visibility in development can be increased and there is room for more ease…
But I strongly advise against viewing null as an error and teaching it as such!
E.g.:
Issues after quality check:
0 –> No issues
1 –> One issue
…
76 –> 76 issues null–> unknown / Not yet checked