I have a tag used in an expression inside a UDT. Sometimes the tag isn't needed, so it's disabled. Of course, now the expression throws an error because the first argument is null. Shouldn't the disabled tag be ignored (i.e. false)?
Is there any nice way around this in the expression?
@nminchin 's last question in his older post was never answered.
Shouldn’t this tag simply be ignored if it’s disabled?
It's nowhere near as simple as that. There's perhaps an argument to be made for this behavior if you're using the tag() expression, but if you're doing a pure interpolation I don't think there's a safe way to manage that.
Consider the following:
"Value: " + {SomeTag}
This scenario is simple enough; ignore the tag by interpolating the disabled tag as an empty string. Easy enough.
But this doesn't hold up for anything more complicated:
# int tags
"Value: " + str({SomeTag})
# or
3 + {SomeTag}
# boolean tags
false or {SomeTag}
The point is the interpolation doesn't know how the value is being used, and so there's no way to supply a safe "fallback" when the tag is disabled.
Would false/0 not be a safe interpretation in all cases?
'Value: ' + str(0) = 'Value: 0'
3 + 0 = 3
false or 0 = false
What about for your string usages?
"Value: " + {SomeTag}
would become... what?
Value: false
Value: 0
Neither is correct for a disabled string Tag.
Presumably either would be at least acceptable, considering there are many more correct use cases for other tag types. Also, if the tag is disabled you're most likely hiding whatever component is displaying the value based on that enabled property.
Would the try() method help out in your case?
https://docs.inductiveautomation.com/display/DOC81/try
You could do something like:
try( {Some Expression #1}, {Some Expression #2} )
most likely, but in this specific case I'm just going to change the disabled tag in question to a memory tag and set the value to false.
That requires an insane amount of foresight and planning. It's highly unlikely anyone can predict the potential of disabling a Tag months or years in the future and incorporate that into all usages of that Tag.
I suspect there's a large contingent who would argue that both of those values are wrong as neither are strings. These examples are also over-simplistic, with their point being there's no way to return any singular value type which would prevent ALL expressions from entering a configuration error state were ewe to go the route of returning some value were the Tag disabled.
I don't know the source code, but could the value returned from a disabled tag be dependent on the type? (i.e. disabled numbers return 0, disabled bools return false, disabled strings return either null or '')
Even if we were to determine the returned value type based on the Tag type, we can't return a value which is not accurate; returning 0 could lead someone to falsely believe that tag is currently holding a value of 0. On the front-end, they have no idea the Tag is disabled.
How naïve I was! Thanks for reminding me 
Nowadays I would use isAvailable from the ignition extensions module to check if the tag is not disabled and found and incorporate that into the expression. Otherwise, as Cody said, there's no way to know what you want the disabled value to be at any given time and project. Today it might be 0, tomorrow it might be 1, or 'invalid', or -1
Sounds like a new tag property to me (disabledValue)