What should null mean when extracting data?
Issue #7
new
Currently, trying to extract a LabVIEW datatype like a number from a null produces default values (like zero for Integers). But it should probably be an error instead. But this this is semi-inconsistent with how we extract clusters, where missing items do not throw an error. Shouldn't a null value for an item be interchangeable with a missing item?
Comments (15)
-
reporter
-
reporter
Made null and NaN an error is extracted as Integer; NaN if as Float.
-
reporter
Also made a useful error message for "Cannot Get as integer: null"
-
It would be nice if we could accept (no error) nulls and return them as the default value for the given data type. Treating null for strings as an empty string could also be a separate idea/option.
JKI JSON Serialization has this option, a boolean “Nulls as Defaults” input to the conversion. I recently had to revert to that, as I kept getting strings returned as null.
-
reporter
Why does your input JSON have nulls at all if they don't mean something different than the item being missing?
Would a possible improvement be a function that deletes all object items that are null? You could use this before converting your JSON.
-
The way missing items are treated now (no error, defaults returned), deleting all null items prior to conversion would work yes.
(The case I am working on right now is that I am consuming JSON from a third party, and if for example a datetime string has no known value, because the first update has not occured yet, their JSON output is a null for that datetime. They also have integer pointers in their structure that return as null if there is nothing to point. Treating those as floats to get them returned as NaN with no error works fine.)
PS. Just to test, I edited the Scalar JSON text to Variant.vi case for strings to check for null first and output an empty string if found, otherwise run the old code. That works as well of course (not keeping that as a solution though, as I want to use the library as standard).
-
FWIW, I’m currently interacting with some JSON returned by SystemLink and they are using null values in lieu of empty strings for some fields. That seems to be causing JSONtext to puke. I guess this yields two questions: 1 - Is SystemLink returning valid JSON, or is this a bug on NI’s side? 2 - Either way, is there a straightforward way of making JSONtext treat “null” as an empty string instead of an error?
-
reporter
See #47, which is the same issue.
-
reporter
Just a note, but JSONtext follows a “best efforts” error-handling strategy, rather than the more typical “puke” strategy. It should be substituting an empty string for the null and continuing on with the conversion of remaining elements. So you could just ignore the 402844 error code.
-
Thanks James. Yeah, you’re right, “Puke” may not have been the best choice of words, I actually really appreciate your error handling; finding the root problem was very obvious. The issue that I’m hitting is that I am converting individual elements of the JSON string to deserialize a class, and doing so in series, so I may hit the error multiple times and it would prevent subsequent executions. Now that I type that out loud however, I realize there’s no need to do it in series and that I could actually do it in parallel. That would remove the need to clear the error after every single conversion, and instead just do it once.
Appreciate the insight!
-
Just as a follow up, in the API I’m interacting with, it turns out null is technically meaningful and distinct from an empty string, so I think the current behavior is actually helpful so that I can delineate between the two cases in some way.
-
reporter
Just FYI, but do you know about the <JSON> tag on LabVIEW strings? This allows extracting fields as JSON text, then looking at the type of that JSON. Allows triggering different code for null versus empty string.
-
No, I don’t think I’m familiar with that. Can you point me to any more information or documentation? (Sorry if I’m oblivious here…)I now see what you’re talking about. That’s nifty. -
reporter
Would a possible improvement be a function that deletes all object items that are null?
I am adding a “Drop Null Object Items” optional input to the “Minify” function. It is easiest to add to Minify, and this seems an intuitive extension of minimising the size of the JSON, for the common use case where null Items are equivalent to missing ones.
-
An optional input on “Difference.vi” to treat empty strings as equivalent to null would also be helpful.
- Log in to comment
Complication: Strict JSON writers substitute null for NaN and Infinity, so for Floats we must accept null as being NaN and no error.