This project has moved and is read-only. For the latest updates, please go here.

JObject could / should(?) ignore null params instead of throwing

Jan 13, 2012 at 12:33 PM
Edited Feb 9, 2012 at 8:25 AM


Sorry, but I want to come back to this.

Consider the following C#:-

    var doc = new JObject(
                new JProperty("eula",
                  new JObject(
                    new JProperty("accepted", eula.Accepted),
                    new JProperty("version", eula.Version),
                    eula.Accepted ? GetJsonLink(/*args removed*/) : null

The GetJsonLink method returns a JProperty.  So if the EULA is accepted I want a JObject with three properties, but if it isn't accepted I want a JObject with two properties.  The trouble is that currently JObject throws an ArgumentException (not an ArgumentNullException, curiously) on receipt of the null in the not-accepted case.  The message is: "Can not add Newtonsoft.Json.Linq.JValue to Newtonsoft.Json.Linq.JObject."

How to get this to work in a nice way?

More specifically: JObject's objection to a null via a thrown exception isn't very useful.  If it simply ignored null (as LINQ to XML does) then that's a far more useful thing, and the above code works nicely.

Thoughts?  Okay if I go ahead and create an Issue for this change?

Jan 13, 2012 at 4:46 PM

Ok, I created a static factory method that creates and returns JObjects, has two overloads (one for "object content" and one for "params object[] content") and which strips out null content values before newing-up JObject.

Nice, but I still think that it would be more useful if JObject ignored nulls, instead of throwing.

If you agree, I'll create the Issue.

Jan 16, 2012 at 1:54 AM

I think in situations like this that you should add the extra property manually.


if (eula.Accepted)
  doc["eula"]["link"] = "Blah";
Jan 16, 2012 at 9:32 AM
Edited Jan 16, 2012 at 2:47 PM

Hi James,

Thanks for looking at this situation.

I prefer the one-statement construction for both Linq to Xml and Linq to Json.  It makes life easier for more complex documents than the one I illustrated.  I find it better to do it this way, rather than construct the basic document in step 1 and then patch in all the conditionals in step 2.  I do believe that the ignoring of null is a very intentional, by-design feature of Linq to Xml to support this kind of scenario (and more complex ones where the selection of an item vs null comes from a LINQ query rather than a simple boolean property).

So I won't create an issue for this, but will continue to use my factory method that filters null content.


Update: referenced my "C# 3.0 in a Nutshell" book, page 367 on Functional Construction (FC).  With FC you build an entire tree in a single expression (as we know).  The benefits are that the code resembles the shape of the [XML or JSON], and it can be incorporated into the select clause of a LINQ query (an example is shown).  One the keys to making this all work (and in fact the first rule that is applied) is having XContainer ignore null content objects.  I really think your JObject (or JContainer) would benefit by following this excellent design, but if you disagree I won't pursue it.  Thanks for your time in considering this matter.

Sep 17, 2014 at 6:16 PM
I completely agree that it would be great if the Linq to Json component ignored nulls. I also agree that it is awkward to come back in a second pass to add the optional properties if you have anything but the most basic of structures. In my case, I'm building JSON for Google Analytics/Google Tag Manager:

Some of those optional fields may or may not be filled in depending on various factors.