Running with Code

Hey Rob,

Many thanks for taking the time to present this to us yesterday evening.

The tool which incorporates LINQ examples that I was talking about is LINQPad (www.linqpad.net) - kudos to Rob Richardson for introducing me to it.

Guy

Rob,
Thanks for posting those slides.

I don't understand this discussion on Object Initializers:

"Always validate input to properties; an exception raised while setting a property will cause a memory leak, even inside try/catch
The object will already be allocated if an exception is raised within a property"

I am not sure how to express what it is that I do not understand, so maybe you can just talk to this a little bit. Typically, I would not validate parameters in an object initializer scenerio (unless they came from an external source, of course, such as user input). For example, if I pull data out of a database (my database) and build an object from it, I would not validate the data first - an exception seems correct in this case (corrupt database data). I also would not fear "memory leaks" because I assume that my "partially-constructed" object would be garbage collected like any properly-constructed object would.

In other words, I image that using object initializers is *equivalent* to (a) creating an object using the default contructor, followed by (b) setting properties. If an exception occurred setting properties - so what? [At least from "memory leak" point of view.]

Joe, I was working on an answer to your question when I realized that it doesn't make sense to me either. I'm sure the object initializer is a compiler-trick and that:

Foo bar = new Foo() { Wokka=3, Doodah="stubble" };

is translated to:

Foo bar = new Foo();
bar.Wokka = 3;
bar.Doodah = "stubble";

by the compiler. He seems to be saying that an exception raised during that assignment will cause a memory leak, which I don't get and hasn't been my experience.