Co-variant array conversion from X to Y may cause run-time exception

Http://stackoverflow.com/questions/8704332/co-variant-array-conversion-from-x-to-y-may-cause-run-time-exception

What it means are this

Control[] controls = new LinkLabel[10]; // compile time legalcontrols[0] = new TextBox(); // compile time legal, runtime exception

And in more general terms

string[] array = new string[10];object[] objs = array; // legal at compile timeobjs[0] = new Foo(); // again legal, with runtime exception

In C #, you is allowed to reference an array of objects (in your case, linklabels) as an array of a base type (in this CAs E, as an array of Controls).

It is also compile time, legal to assign another object, which is a to the Control array.

The problem is, the array of Controls that are not actually an array.

At runtime, it's still an array of linklabels.

As such, the assignment, or write, would throw an exception.

Http://blogs.msdn.com/b/ericlippert/archive/2007/10/17/covariance-and-contravariance-in-c-part-two-array-covariance.aspx

Covariance and Contravariance in C #, part Two:array covariance

C # implements variance in the ways. Today, the broken.

Ever since C # 1.0, arrays where the element type is a reference type is covariant. This is perfectly legal:

animal[] animals = new GIRAFFE[10];

Since Giraffe is smaller than Animal, and ' make an array of ' is a covariant operation on types, giraffe[] is s Maller thananimal[], so a instance fits into that variable.

Unfortunately, this particular kind of covariance is broken. It is added to the CLR because Java requires it and the CLR designers wanted to being able to support java-like languages. We and added it to C # because it is in the CLR. This decision is quite controversial at the time and I am not very happy about it, but there's nothing we can does about it Now.

Why are this broken? Because It should always is legal to put a Turtle into an array of Animals. With array covariance in the language and runtime your cannot guarantee that an array of Animals can accept a Turtle Because the backing store might actually is an array of giraffes.

This means, we have turned a bug which could is caught by the compiler into one so can only is caught at runtime. This also means, every time you put an object into an array we have to do a run-time check to ensure that the type wor KS out and throw an exception if it doesn ' t. That's potentially expensive if you ' re putting a zillion of these things into the array.

Yuck.

Unfortunately, we ' re stuck with this now. giraffe[] is smaller than animal[], and that ' s just the It goes.

I would like-to-take the opportunity to clarify some points brought up in comments to part one.

First, by "subtype" and "supertype" I mean "are on the chain of base classes" for classes and "are on the tree of Base Inter Faces "for interfaces. I do not mean the most general notion of "was substitutable for". And by ' bigger than ' and ' smaller than ' I explicitly do not mean ' is a supertype of ' and ' is a subtype of '. It's the case that every subclass was smaller than its superclass, yes, butNot vice versa. That's, it's not the case that every smaller type was a subtype of its larger type.giraffe[] is smaller than both animal[] and System.Array. Clearly giraffe[] is a subtype of the System.Array, but it'semphatically not a subtype of animal[]. Therefore the "is smaller than" relationship I am defining are more general than the "is a kind of" relationship. I want to draw a distinction between assignment compatibility (smaller than) and inheritance (subtype of).

Next time we ' ll discuss a kind of variance that we added to C # 2.0 which are not broken.

Co-variant array conversion from X to Y may cause run-time exception