We had an issue at production yesterday where the system tried to access a property inside an empty string.Looking more closely, we discovered that the a!fromJson is not doing as it was supposed to do.
Here on the a!fromJson (21.1) documentation, we see that the property with an empty string it's converted to null
But when we execute the same code on the expressions, this comes back as an empty string, not maintaining its described functionality.
The problem is that when we try to access a property from a null value, it does not throw an error.
But when we try to access a property from a Text it throws an error and we know how problematic those are
Discussion posts and replies are publicly visible
As an aside, I always recommend using the property() function when accessing a CDT or dictionary property from an object when you're not sure whether it'll actually have that property. This allows you to sidestep even needing error messages. If you really require a system error, you could look into using error() depending on whatever result you're returned from the property() function.
Agreed with Mike - it's always better to use a function that allows for null checking like property() or index(). Also one thing to keep in mind: "" is also considered null. For instance, if you try
"" = null
Mike SchmittYeap, we fixed using the index function to get the value if it is present, thanks for the suggestion.But isn't error() or even try() undocumented ?
error() is a supported function while try() is not.
Yes, it's safer, but is verbose as hell.Of course safety is more important, but who did this tried to access the fifth property on a chain, like this:
We fixed with something like this:
But the problem here is not the amount of code to solve this, but the divergence between what was documented to its actual behavior.Question/Suggestion:Can't Appian just ignore all of those properties ahead of the variables if the variable is not of a dictionary/CDT type as it "does" to null, for example ?
Nice, thanks , found its documentation here didn't know about it Thanks
Do this
if( isnull(ri!path), ri!data, reduce( index(_,_,ri!default), ri!data, ri!path ) )
Where path is a list of a mix of field names and indexes.
On my normal soapbox: index() and property() have allegedly identical functionality, but as usual i must insist that you consider using them for their namesake purposes. That is to say, if you're getting an index (i.e. a position in an array), use index(). If you're getting a property (i.e. a dot property member of a CDT or dictionary), use property(). When code gets more complex this dramatically increases readability later on. There are zero reasons not to do this.
Yes, it's a nice approach.We usually just learn the index function first and as the property does a part of the same job the index does we usually forget about it and use index for everything.But for readability, it is much better as it speaks out what it is doing there on the code, getting a property.In fact, seems that index is the one that does more stuff "than it should do" looking only by its name.Even if some languages have named indexes already, don't know maybe I am being a little old school here hahahahah
But, thanks for the tip Mike Schmitt
Great solution, I prefer using split to a Text path instead of using an array.