I run into runtime NullReferenceException exception in the following code:
public class Container
{
public IList<string> Items { get; set; }
}
class Program
{
static void Main(string[] args)
{
var container = new Container() { Items = {"Test"} };
}
}
It's logical that compiller couldn't create interaface instance but I got a runtime exception, not a compile time. I was confused even more when I investigated this behavior further:
var container = new Container() { Items = {} }; //Legal, Items is null after initialization
var container = new Container() { Items = { "Test" } }; //Legal, throws exception
container.Items = {}; //Illegal doesn't compile
container.Items = {"Test"}; //Illegal doesn't compile
Is this some kind of bug or I don't understand something?
And I'm using .net framework 4.0
It compiles, because compiler has no knowledge about is the List already initialized somewhere else. You can make it work by adding initialization into a constructor:
public class Container
{
public IList<string> Items { get; set; }
public Container()
{
Items = new List<string>();
}
}
Or changing the property to hide a field, which is initialized when class instance is created:
private IList<string> items = new List<string>();
public IList<string> Items
{
get { return items; }
set { items = value; }
}
Then, var container = new Container() { Items = { "Test" } }; works just fine.
At runtime .Add() method is called for every item in collection initializer group. When property is not initialized with new List<string> it has null value, and that's why NullReferenceException is thrown.
Object and Collection Initializers (C# Programming Guide)
By using a collection initializer you do not have to specify multiple
calls to the Add method of the class in your source code; the compiler
adds the calls.
you didn't initialize the List
var container = new Container() { Items = new List<string>() { "Test" } };
By the way the below is legal as for the compiler there is nothing wrong with it (syntax is correct,etc)
var container = new Container() { Items = {} };
but because the compiler doesn't know that Items list has not been initialized (you are not passing any item in the collection initializator {}) the .Add method won't be called on the List and the run-time won't know that the Items object is null
On the other hand the below is legal for the compiler but it throws an exception at run time because you try to initialize the the list passing an item (it is correct for the compiler for the same reason explained above) so when the run time will call the .Add method behind the scene, it will throw a null reference exception because Items has not been initialized
var container = new Container() { Items = { "Test" } };
Related
This question already has answers here:
Why Collection Initialization Throws NullReferenceException
(4 answers)
Closed 1 year ago.
Why isn't a collection initializer honored in an object initializer?
public class Foo
{
public string[] Bar { get; set; }
public Foo() { }
}
class Program
{
static void Main(string[] args)
{
var foo = new Foo()
{
Bar = { }
};
Assert.Null(foo.Bar); // Null not empty...what gives?
}
}
The expectation is that the underlying array will be set to an initialized empty collection.
That way of initializing a new collection is rewritten internally as Bar.Add() for each element, and since you aren't adding anything to it it will not generate any calls to .Add().
If you decompile that it will look like this (notice how the initialization is lost).
private static void Main(string[] args)
{
new Foo();
}
You can try by actually adding a string to your initialization. It won't compile but show the error below.
var foo = new Foo()
{
Bar = { "" }
};
error CS1061: 'string[]' does not contain a definition for 'Add' and no accessible extension method 'Add' accepting a first argument of type 'string[]' could be found (are you missing a using directive or an assembly reference?)
Now if you initialize it with a new array it will of course work.
var foo = new Foo()
{
Bar = new[] { "" }
};
Checking this dempiled yields this.
private static void Main(string[] args)
{
Foo foo = new Foo();
string[] array = new string[1];
array[0] = "";
foo.Bar = array;
}
So in short, initialize your array in your class constructor to be safe.
It is because default(string[]) is null. You must initialize it, and you could use a constructor for it:
public class Foo
{
public string[] Bar { get; set; }
public Foo()
{
Bar = new string[0];
}
}
In this case, it will instance a new empty array on Bar property.
If a collection initializer is used as part of a member initializer, a new collection will not be instantiated. It is simply syntactic sugar for calling the Add(...) method on the collection.
Note that in this (slightly modified) example, a NullReferenceException is thrown:
public class Foo
{
public List<string> Bar { get; set; }
}
void Main()
{
var foo = new Foo()
{
Bar = { "hello" }
};
}
The C# spec defines this behaviour in section 7.6.10.2:
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 field or property, the elements given in the initializer are added to the collection referenced by the field or property.
I am not sure why you declaring an array this way, you may do what #Felipe Oriani mentioned but I assume you know that and you just trying to understand why your way is not working as it should work. So I will try relate to this and not the best practices of the way of declaring an array.
That's an interesting question as I found some weird things while trying to understand why it happens.
I noticed that if I am initializing it in the constructor with braces, it won't compile (invalid expression term '{'). Not sure why it doesn't compile and the other ways do compile?!
public Foo()
{
Bar = { };
}
Then I mentioned that if I am declaring it not inside an object it works well:
string[] bar = { }; // Creates an empty array of strings
So it would be possible to do it and it will work as you expects:
public class Foo
{
public string[] Bar { get; set; }
public Foo(string[] bar)
{
Bar = bar;
}
}
class Program
{
static void Main(string[] args)
{
string[] bar = { };
var foo = new Foo(bar); // foo.Bar is not empty string array
}
}
Consider the following code:
public sealed class Order
{
public Order()
{
Items = new List<OrderItem>();
}
public List<OrderItem> Items { get; private set; }
}
public sealed class OrderItem
{
}
and here's Order initialization in another class.
var order = new Order
{
Items =
{
new OrderItem(),
new OrderItem()
}
};
Could you explain why it works? As you see the Order has private set property, so I thought it would be impossible to set its value.
Your statement works because the collection initialization syntax uses the Add() method to add the items to the collection rather than setting the member to a new instance of a collection. Essentially, your code is the equivalent of:
var order = new Order();
order.Items.Add(new OrderItem());
order.Items.Add(new OrderItem());
Which is fine since you only ever use the getter method.
Short answer:
It works thru collection initializer which calls Add to add items
Long answer:
Accodingly C# 3.0 cpesification, object which implement IEnumerable and has appropiate Add method can be initialised thru the Add method.
Items has public get accessor and Items it's a List<T> which implements IEnumerable and has Add. Here's how the compiler sees your code
var order = new Order();
order.Items.Add(new OrderItem());
order.Items.Add(new OrderItem());
Please note, the compiler doesn't use info that the List implements IEnumerable, here's the proof, no exception will be thrown
public sealed class Order
{
public Order()
{
Items = new MyCollection();
}
public MyCollection Items { get; private set; }
}
public sealed class OrderItem
{
}
public class MyCollection : IEnumerable
{
private readonly List<OrderItem> _items = new List<OrderItem>();
public void Add(OrderItem item)
{
_items.Add(item);
}
public IEnumerator GetEnumerator()
{
throw new NotImplementedException();
}
}
from C# Language Specification
The collection object to which a collection initializer is applied
must be of a type that implements System.Collections.IEnumerable or
a compile-time error occurs. For each specified element in order, the
collection initializer invokes an Add method on the target object with
the expression list of the element initializer as argument list,
applying normal overload resolution for each invocation. Thus, the
collection object must contain an applicable Add method for each
element initializer.
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.
Consider the following code:
public sealed class Order
{
public Order()
{
Items = new List<OrderItem>();
}
public List<OrderItem> Items { get; private set; }
}
public sealed class OrderItem
{
}
and here's Order initialization in another class.
var order = new Order
{
Items =
{
new OrderItem(),
new OrderItem()
}
};
Could you explain why it works? As you see the Order has private set property, so I thought it would be impossible to set its value.
Your statement works because the collection initialization syntax uses the Add() method to add the items to the collection rather than setting the member to a new instance of a collection. Essentially, your code is the equivalent of:
var order = new Order();
order.Items.Add(new OrderItem());
order.Items.Add(new OrderItem());
Which is fine since you only ever use the getter method.
Short answer:
It works thru collection initializer which calls Add to add items
Long answer:
Accodingly C# 3.0 cpesification, object which implement IEnumerable and has appropiate Add method can be initialised thru the Add method.
Items has public get accessor and Items it's a List<T> which implements IEnumerable and has Add. Here's how the compiler sees your code
var order = new Order();
order.Items.Add(new OrderItem());
order.Items.Add(new OrderItem());
Please note, the compiler doesn't use info that the List implements IEnumerable, here's the proof, no exception will be thrown
public sealed class Order
{
public Order()
{
Items = new MyCollection();
}
public MyCollection Items { get; private set; }
}
public sealed class OrderItem
{
}
public class MyCollection : IEnumerable
{
private readonly List<OrderItem> _items = new List<OrderItem>();
public void Add(OrderItem item)
{
_items.Add(item);
}
public IEnumerator GetEnumerator()
{
throw new NotImplementedException();
}
}
from C# Language Specification
The collection object to which a collection initializer is applied
must be of a type that implements System.Collections.IEnumerable or
a compile-time error occurs. For each specified element in order, the
collection initializer invokes an Add method on the target object with
the expression list of the element initializer as argument list,
applying normal overload resolution for each invocation. Thus, the
collection object must contain an applicable Add method for each
element initializer.
Through some random object creation today I came across this neat little shortcut for a Dictionary<K, V>. Is the following assignment a compiler shortcut or is it a feature of Dictionary<string, string>.
IDictionary<string, string> items = { { "item1key", "item1value" } };
Looking at the source for Dictionary<K, V> I don't see anything offhand for how this works. Implementing all the interfaces for this class dot not allow me to perform a similar operation. Why is it that we can do it for a dictionary but not another type. For example, how does the compiler or language feature know that the first item is a key and the second item is the value. Or even more specific this same syntax can't be used for a List<string>
List<string> items = { "item1" };
So the first is valid, why?
I'm not necessarily trying to duplicate this but rather curious as to why it is the way it is. What makes a dictionary special in this case?
Example that works
public class Button
{
public string Title { get; set; }
public ButtonType Type { get; set; }
public IDictionary<string, string> Items { get; set; }
public bool RequiresSelected { get; set; }
}
var buttons = new List<Button>
{
new Button {
Items = {
{"button1", "Button 1"},
{"button2", "Button 2"},
{"button3", "Button 3"},
},
Title = "3 Buttons",
Type = ButtonType.DropDown
}
};
The syntax you've shown isn't valid in C#. You'd need:
IDictionary<string, string> items = new Dictionary<string, string>
{ { "item1key", "item1value" } };
At that point it's just a normal collection initializer, so the list equivalent would be:
List<string> items = new List<string> { "item1" };
EDIT: Let's see if my edit can beat yours. My guess is that you've seen something like:
var foo = new Foo {
SomeDictionaryProperty = {
{ "item1key", "item1value" }
}
};
That's an embedded collection initializer, and can be used for lists too. It's not creating a new dictionary, it's adding to an existing one. The code above is equivalent to:
var tmp = new Foo();
tmp.SomeDictionaryProperty.Add("item1key", "item1value");
var foo = tmp;
Another example of it working:
var form = new Form {
Controls = { new Label { Text = "Foo"}, new Label { Text = "Bar" } }
};
See section 7.6.10.2 of the C# 4 specification (Object Initializers) for more information. The important bit is this:
member-initializer:
identifier = initializer-value
initializer-value:
expression
object-or-collection-initializer
So you can initialize a property to either be a specific value (in which case the setter will be used) or via an object/collection initializer, in which case the getter for the property will be used, and then setters or the Add method will be used for the body of the object/collection initializer.
This is a feature of C# compiler, and the dictionary is not special: any collection that supports Add can be initialized in this way. The details are in the section 7.6.10.3 of the C# Language Specification 4.0.
The collection object to which a collection initializer is applied must be of a type that implements System.Collections.IEnumerable or a compile-time error occurs. For each specified element in order, the collection initializer invokes an Add method on the target object with the expression list of the element initializer as argument list, applying normal overload resolution for each invocation. Thus, the collection object must contain an applicable Add method for each element initializer.