The following testcase throws a null-reference exception, when it tries to assign Id to an object which is null, since the code is missing the "new R" before the object initializer.
Why is this not caught by the compiler? Why is it allowed, in which use-cases would this be a meaningful construct?
[TestClass]
public class ThrowAway
{
public class H
{
public int Id { get; set; }
}
public class R
{
public H Header { get; set; }
}
[TestMethod]
public void ThrowsException()
{
var request = new R
{
Header =
{
Id = 1
},
};
}
}
The compiler doesn't give a warning because you could have:
public class R
{
public H Header { get; set; }
public R()
{
Header = new H();
}
}
so Header could be initialized by someone/something. Solving if someone/something will initialize Header is a complex problem (probably similar to the Halting problem)... Not something that a compiler wants to solve for you :-)
From the C# specifications:
A member initializer that specifies an object initializer after the equals sign is a nested object initializer, i.e. an initialization of an embedded object. Instead of assigning a new value to the field or property, the assignments in the nested object initializer are treated as assignments to members of the field or property. Nested object initializers cannot be applied to properties with a value type, or to read-only fields with a value type.
We are in the case of nested initializer, and see the bolded part. I didn't know it.
Now, note that new R { } is, by C# spec, an 7.6.10.1 Object creation expressions followed by an object-initializer, while the Header = { } is a "pure" 7.6.10.2 Object initializers.
Related
I am currently in the progress of enabling non-nullable reference types for my .net core api.
The problem is that the integrationtest fails when trying to deserializeObject because it has no empty constructor. I can't have an empty constructor because that will make property: possible null.
The problem:
JsonConvert.DeserializeObject<ViewModel>(result); calls the constructor which has a constructor with an object argument ViewModel(Model model). In the test this is null.
I have made a simple sample:
The api:
public class Dog
{
public string Name { get; set; } = null!;
}
public class DogViewModel
{
public DogViewModel(Dog dog)
{
Name = dog.Name;
}
public string Name { get; set; }
}
[HttpGet]
[Route("dog")]
public DogViewModel GetDog()
{
var dog = new Dog
{
Name = "Fido"
};
return new DogViewModel(dog);
}
This works when I use a client to call the api, but it fails from the tests:
Test
[Fact]
public async Task GetDog()
{
var response = await Client.GetAsync("dog");
var result = response.Content.ReadAsStringAsync().Result;
Assert.True(response.IsSuccessStatusCode, result);
var responeseAsObject = JsonConvert.DeserializeObject<DogViewModel>(result); <----- this is where it breaks
Assert.IsType<string>(responeseAsObject.Name);
Assert.NotNull(responeseAsObject);
}
JsonConvert.DeserializeObject calls the constructor of DogViewModel; DogViewModel(Dog dog), but dog is null.
Populate the class with default values. With null able reference types, the default value would be null, so in your case just assign the default value that you expect.
public class ClassName
{
public ClassName()
{
Name = string.Empty; //Default value
}
public ClassName(Dog dog)
{
Name = dog.Name;
}
}
Or
public class ClassName
{
public string Name { get; set; } = string.Empty;
public ClassName() {}
public ClassName(Dog dog)
{
Name = dog.Name;
}
}
The serializer will construct a new object. The object contains a string member, and you have disabled null-able reference types. Thus you need to specify what the value will be when the object is created.
If you don't want to use the default constructor (An empty constructor), you can tell the serialiser the constructor you would like to use:
https://www.newtonsoft.com/json/help/html/JsonConstructorAttribute.htm
That's correct behavior JsonConvert.DeserializeObject uses constructor to just create an object. It won't pass any parameter to it and that's why you are getting an error.
What's happening is, dog is null and hence your assignment of Name = dog.Name; throws NullreferenceException.
You should ideally check dog for null before using it in your constructor.
public DogViewModel(Dog dog)
{
Name = dog?.Name;
}
The question is, as #CodeCaster points out, nonsensical- But i found a non-optimal solution.
In the test project i created this:
public class TestDogViewModel : DogViewModel
{
public TestDogViewModel() : base(new Dog {Name = ""})
{
}
}
When deserializing i used this:
var responeseAsObject = JsonConvert.DeserializeObject<TestDogViewModel>(result);
Developers won't use this viewModel by mistake since the project doesn't have a reference to the test project,
So now if you want to have a DogViewModel you would need to have a dog. It kinda makes more sense in my real project :S.
From docs.microsoft:
The Newtonsoft.Json [JsonConstructor] attribute lets you specify which constructor to call when deserializing to a POCO. System.Text.Json supports only parameterless constructors. As a workaround, you can call whichever constructor you need in a custom converter.
--> https://learn.microsoft.com/en-us/dotnet/standard/serialization/system-text-json-migrate-from-newtonsoft-how-to#deserialize-to-immutable-classes-and-structs
Maybe this could be a solution
C# 5.0 Language Specification 7.6.10.2 Object initializers states that
A member initializer that specifies an object initializer after the
equals sign is a nested object initializer, i.e. an initialization of
an embedded object. Instead of assigning a new value to the field or
property, the assignments in the nested object initializer are treated
as assignments to members of the field or property. Nested object
initializers cannot be applied to properties with a value type, or to
read-only fields with a value type.
While I understand read-only fields cannot be modified by the initializers after the constructor is run, I do not have a clue about the restriction on properties.
The following is a code sample I used to test this restriction on properties:
using System;
namespace ObjectCollectionInitializerExample
{
struct MemberStruct
{
public int field1;
public double field2;
}
class ContainingClass
{
int field;
MemberStruct ms;
public int Field
{
get { return field; }
set { field = value; }
}
public MemberStruct MS
{
get { return ms; }
set { ms = value; }
}
}
class Program
{
static void Main(string[] args)
{
// Nested object initializer applied to a property of value type compiles!
ContainingClass cc = new ContainingClass { Field = 1, MS = new MemberStruct { field1 = 1, field2 = 1.2} };
Console.ReadKey();
}
}
}
I commented on the code where it was supposed to generate a compiler error based on the specification. But it compiles successfully. What am I missing here?
Thanks
What you have is not a nested object initializer because you explicitly create a new instance of MemberStruct. The inner object initializer doesn't directly follow the equals sign, but is an object initializer on its own associated with the call to the MemberStruct constructor.
This is how using a nested object initializer would look like:
ContainingClass cc = new ContainingClass { Field = 1, MS = { field1 = 1, field2 = 1.2} };
This will not compile when MS is a value type (struct), but it will compile when MS is a reference type (object).
The following combination of object and collection initializers does not give compilation error, but it is fundamentally wrong (https://learn.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/object-and-collection-initializers#examples), because the Add method will be used in the initialization:
public class Foo
{
public List<string> Bar { get; set; }
}
static void Main()
{
var foo = new Foo
{
Bar =
{
"one",
"two"
}
};
}
So you'll get NullReferenceException. What is the reason for making such an unsafe decision while developing the syntax of the language? Why not to use initialization of a new collection for example?
First, it's not only for combination of object and collection initializers. What you are referring here is called nested collection initializers, and the same rule (or issue by your opinion) applies to nested object initializers. So if you have the following classes:
public class Foo
{
public Bar Bar { get; set; }
}
public class Bar
{
public string Baz { get; set; }
}
and you use the following code
var foo = new Foo
{
Bar = { Baz = "one" }
};
you'll get the same NRE at runtime because no new Bar will be created, but attempt to set Baz property of the Foo.Bar.
In general the syntax for object/collection initializer is
target = source
where the source could be an expression, object initializer or collection initializer. Note that new List<Bar> { … } is not a collection initializer - it's an object creation expression (after all, everything is an object, including collection) combined with collection initializer. And here is the difference - the idea is not to omit the new, but give you a choice to either use creation expression + object/collection initializer or only initializers.
Unfortunately the C# documentation does not explain that concept, but C# specification does that in the Object Initializers section:
A member initializer that specifies an object initializer after the equals sign is a nested object initializer, i.e. an initialization of an embedded object. Instead of assigning a new value to the field or property, the assignments in the nested object initializer are treated as assignments to members of the field or property. Nested object initializers cannot be applied to properties with a value type, or to read-only fields with a value type.
and
A member initializer that specifies a collection initializer after the equals sign is an initialization of an embedded collection. Instead of assigning a new collection to the target field, property or indexer, the elements given in the initializer are added to the collection referenced by the target.
So why is that? First, because it clearly does exactly what you are telling it to do. If you need new, then use new, otherwise it works as assignment (or add for collections).
Other reasons are - the target property could not be settable (already mentioned in other answers). But also it could be non creatable type (e.g. interface, abstract class), and even when it is a concrete class, except it is a struct, how it will decide that it should use new List<Bar> (or new Bar in my example) instead of new MyBarList, if we have
class MyBarList : List<Bar> { }
or new MyBar if we have
class MyBar : Bar { }
As you can see, the compiler cannot make such assumptions, so IMO the language feature is designed to work in the quite clear and logical way. The only confusing part probably is the usage of the = operator for something else, but I guess that was a tradeoff decision - use the same operator = and add new after that if needed.
Take a look at this code and the output of it due to the Debug.WriteLine():
public class Foo
{
public ObservableCollection<string> _bar = new ObservableCollection<string>();
public ObservableCollection<string> Bar
{
get
{
Debug.WriteLine("Bar property getter called");
return _bar;
}
set
{
Debug.WriteLine("Bar allocated");
_bar = value;
}
}
public Foo()
{
_bar.CollectionChanged += _bar_CollectionChanged;
}
private void _bar_CollectionChanged(object sender, NotifyCollectionChangedEventArgs e)
{
Debug.WriteLine("Item added");
}
}
public MainWindow()
{
Debug.WriteLine("Starting..");
var foo = new Foo
{
Bar =
{
"one",
"two"
}
};
Debug.WriteLine("Ending..");
}
The output is:
Starting..
Bar property getter called
Item added
Bar property getter called
Item added
Ending..
For you questions:
What is the reason for making such an unsafe decision while developing the syntax of the language? Why not to use initialization of a new collection for example?
Answer:
As you can see the intention of the designer of that feature was not to reallocate the collection but rather to help you add items to it more easily considering that you manage your collection allocation by yourself.
Hope this clear things out ;)
Consider the following code:
class Program
{
static void Main()
{
var foo = new Foo
{
Bar =
{
"one",
"two"
}
};
}
}
public class Foo
{
public List<string> Bar { get; set; } = new List<string>();
}
The compiler does not know whether you already created a new list instance within the class constructor (or in another method).
Recall that collection initializer is a series of calls to Add method on an existing collection!
See also:
Custom Collection Initializers
Also note that this initializer applies to a collection that was exposed as a property. Hence the collection initializer is possible as part of the outer object initializer (the Foo object in your example).
However, if it was a simple variable, the compiler would not let you to intialize the collection this way. Here is an example:
List<string> list =
{
"one",
"two"
};
This will throws a compilation error.
As last example, the output of the following code will be: "one, two, three, four, ". I think that now you understand why.
Pay attention to the list static instance, as well as to the private modifier in the "set" of the Bar property, which does not matters because the initializer just calls the Add method, which is accessible even when the Bar "set" is private.
class Program
{
static void Main()
{
var foo1 = new Foo
{
Bar =
{
"one",
"two"
}
};
var foo2 = new Foo
{
Bar =
{
"three",
"four"
}
};
PrintList(foo1.Bar);
}
public static void PrintList(List<string> list)
{
foreach (var item in list)
{
Console.Write(item + ", ");
}
Console.WriteLine();
}
}
public class Foo
{
private static readonly List<string> _bar = new List<string>();
public List<string> Bar { get; private set; } = _bar;
}
I believe the key thing to understand here is that there are two syntactic sugar flavors at play (or at least, there should be):
Object Initialization
Collection Initialization
Take away the List for a moment and look at the field as an object:
public class Foo
{
public object Bar { get; set; }
}
When using Object Initialization, you assign an object (or null):
var foo = new Foo()
{
Bar = new object(); //or Bar = null
}
Now, let's go back to your original example and slap Collection Initialization on top of this. This time around, the compiler realizes this property implements IEnumerable and the array you have provided is of the right type, so it attempts to call the Add method of the interface. It must first go looking for the object, which in your case is null because you haven't initialized it internally. If you debug through this, you will find that the getter gets called and returns null, hence the error.
The correct way of mixing both features then would be for you to assign a new object that you initialize with your values:
var foo = new Foo()
{
Bar = new List<string>(){ "one", "two" }
};
If you debug this version, you will find that the setter is called instead, with the new instance you initialized.
Alternatively, you can initialize your property internally:
public List<string> Bar { get; set; } = new List<string>();
If you debug this version, you will find that the property is first initialized with a value and your version of the code then executes without error (by calling the getter first):
var foo = new Foo()
{
Bar = {"one", "two"}
};
To illustrate the syntactic sugar aspect, Collection Initialization only works within the confines of a constructor calling statement:
List<string> bar = {"one", "two" }; //ERROR: Can only use array initializer expressions to assign to array types. Try using a new expression instead.
List<string> bar = new[] { "one", "two" }; //ERROR: Cannot implicitly convert type 'string[]' to 'System.Collections.Generic.List<string>'
List<string> bar = new List<string>() { "one", "two" }; //This works!
If you wish to allow initialization like in your original example, then the expectation is that the variable will be set to an instance before the Add method can be called. This is true whether you use syntactic sugar or not. I could just as well run into the same error by doing this:
var foo = new Foo();
foo.Bar.Add("one");
So you may want to initialize the variable in order to cover all bases, unless of course a null value has a semantic meaning in your application.
What is going on with this C# code? I'm not even sure why it compiles. Specifically, what's going on where it's setting Class1Prop attempting to use the object initializer syntax? It seems like invalid syntax but it compiles and produces a null reference error at runtime.
void Main()
{
var foo = new Class1
{
Class1Prop =
{
Class2Prop = "one"
}
};
}
public class Class1
{
public Class2 Class1Prop { get; set; }
}
public class Class2
{
public string Class2Prop { get; set; }
}
This is allowed by object initializer syntax in the C# specification, where it is called a nested object initializer. It is equivalent to:
var _foo = new Class1();
_foo.Class1Prop.Class2Prop = "one"
var foo = _foo;
It should be a little more obvious why this throws a null reference exception. Class1Prop was never initialized in the constructor of Class1.
The benefit of this syntax is that the caller can use the convenient object initializer syntax even when the properties are getter-only to set mutable properties on nested objects. For example, if Class1Prop was a getter-only property the example is still valid.
Note that there is an inaccessible temporary variable created to prevent the access of a field or array slot before the full initialization has run.
Can one tell me, why the heck does it compile?
namespace ManagedConsoleSketchbook
{
public interface IMyInterface
{
int IntfProp
{
get;
set;
}
}
public class MyClass
{
private IMyInterface field = null;
public IMyInterface Property
{
get
{
return field;
}
}
}
public class Program
{
public static void Method(MyClass #class)
{
Console.WriteLine(#class.Property.IntfProp.ToString());
}
public static void Main(string[] args)
{
// ************
// *** Here ***
// ************
// Assignment to read-only property? wth?
Method(new MyClass { Property = { IntfProp = 5 }});
}
}
}
This is a nested object initializer. It's described in the C# 4 spec like this:
A member initializer that specifies an object initializer after the equals sign is a nested object initializer - that is, an initialization of an embedded object. Instead of assigning a new value to the field or property, the assignments in the nested object initializer are treated as assignments to members of the field or property. Nested object initializers cannot be applied to properties with a value type, or to read-only fields with a value type.
So this code:
MyClass foo = new MyClass { Property = { IntfProp = 5 }};
would be equivalent to:
MyClass tmp = new MyClass();
// Call the *getter* of Property, but the *setter* of IntfProp
tmp.Property.IntfProp = 5;
MyClass foo = tmp;
Because you are using the initializer which uses the setter of ItfProp, not the setter of Property.
So it will throw a NullReferenceException at runtime, since Property will still be null.
Because
int IntfProp {
get;
set;
}
is not readonly.
You did not invoke setter of MyClass.Property, just getter.