Comments on: ColdFusion null Gotcha

By: barneyb

barneyb — Fri, 02 Aug 2013 04:14:02 +0000

I'm sorry, I assumed you were referring to CF structs, not JSON packets. The impetus for my original post was the inability to differentiate between nulls in JSON, exactly as your packets illustrate.

By: D

Thu, 01 Aug 2013 22:28:07 +0000

That didn't work (using CF9; is it different in CF10?). The following returned YES for both tests, and keys in both contained the string value "null":


map1 = DeserializeJSON('{"name" : null}');
map2 = DeserializeJSON('{"name" : "null"}');



key 'name' exists in map1:  #structKeyExists(map1, 'name')#
key 'name' exists in map2:  #structKeyExists(map2, 'name')#

By: barneyb

barneyb — Thu, 01 Aug 2013 22:07:44 +0000

D, Assuming you deserialize into 'map', then #structKeyExists(map, 'name')# will return 'false' for the first and 'true' for the second.

By: D

Thu, 01 Aug 2013 22:05:12 +0000

So is there a way to test the difference between {"name" : null} and {"name" : "null"} after deserialization?

By: barneyb

barneyb — Sun, 01 May 2011 00:09:03 +0000

Ben, that's exactly the problem which manifested this post. It was in another developer's app, inverted, and was a normal struct (not the arguments scope), but that's the gist of it. CF rather screwed up in making null behave both ways. It was pretty much masked until recently, but the simple fact is that if you run on the JRE you have nulls, and any JRE language needs to acknowledge that fact.

By: barneyb

barneyb — Sun, 01 May 2011 00:08:55 +0000

Matt, I disagree. Historically, a null value was "missing" in CFML parlance, and rightfully so. In CF9, Adobe added isNull to differentiate the two cases (because it's needed for using Hibernate), but there's a LOT of code sitting around which equates a null value to missing. Your test about JSON serialization is flawed. Obviously the serialized version of a null will be the string "null". That's stipulated by the JSON spec. And that's what your test was checking. For purposes of comparison, I've rewritten it here:

StringBuilder sb = new StringBuilder();
new JavaScriptSerializer().Serialize(null, sb);
assert sb.ToString() == null; // false - will be "null"

I don't know C#, but your test needs to be something like this (forgive the erroneous types and syntax):

StringBuilder sb = new StringBuilder();
new JavaScriptSerializer().Serialize(null, sb);
Object theValue = new JavaScriptDeserializer().Deserialize(sb.toString());
assert theValue == null; // true

You have to deserialize to get back to the environment - the serialized format is always strings.

By: Ben Nadel

Ben Nadel — Wed, 27 Apr 2011 21:45:19 +0000

Another interesting thing about NULL struct keys is that they are still available during struct iteration (ie. collection loop). I ran into that once when looping over non-required CFArgument keys — they were in the loop but caused a problem when I tried to reference them.

By: Matt Osbun

Matt Osbun — Wed, 27 Apr 2011 18:21:18 +0000

Treating a null value of a struct as if it were missing is dangerous, I think, and should probably be reported as a bug. I have a hard time imagining how that behavior could be right.

With the serialization, however, I'm not sure that's a bug. Or even all that unusual or unexpected. I did a quick test in C#:

StringBuilder sb = new StringBuilder();
new JavaScriptSerializer().Serialize(null, sb);

At the end of this, sb will have the string value of "null", and sb.ToString() == null will evaluate as false. Which makes sense, really. JSON serializes an object and returns a string value. If a null value didn't have some kind of string representation, I think it would break the JSON formatting.