:( Is nowhere safe!?

Oh my FREAKING God.... That makes me twitch. That's such a horrible security flub.

I believe it is. You're leaving data integrity up to the USERS! Are you kidding me!? :omg: Data integrity is everything. You can always index and perform other optimizations if you want to speed things up, even throw hardware at it if necessary, but fixing corrupted data is a nightmare with no easy solution. Given the horsepower of modern systems, there's no excuse for not using this important feature.

Fair enough. :)

It's not THAT horrible. Yes, it's not exactly elegant, but sometimes this is done to make things clearer to other coders (especially less-experienced ones).

norm .net wrote:

Whats good about VB, absolutely nothing, zilch.

My first post on this board is in vehement agreement with this wise poster. :) Hello!

I do understand it now. From a functional perspective, they're no different, but from a conceptual and practice perspective, it keeps the acts of Setting and Getting separate from one another. Thanks again, Scott. :)

That makes sense, and I appreciate your taking the time to answer, Scott. :) This seems functionally equivalent to what I described, which is great, but I'm quite not certain what this method buys me. Predictability? What is your reasoning for doing this? I really want to understand.

So in this example, what is use of preventing assignment of the member object to null? I'd still have to be prepared for null values to come back from the Name property, so if I'm prepared for that in my code, why would I then prevent the ability to set it to null? Though it seems like your example now tells the user that there was an attempt to write to the member object at some point because it is no longer null, whereas in mine, you never know if anyone tried to set it.

I've been wrestling with the idea of defaulting member variables, not necessarily in the constructor, but in their accessor properties. For example:

private string _name;

public string Name
{
    get
    {
        if (this._name == null) this._name = String.Empty;
        return this._name;
    }
    set { this._name = value; }
}

This way, I know that, no matter what, whenever I access MyObject.Name, I'll be getting a valid string object and never a null, so that when I go to do MyObject.Name.Trim(), I'll never get a null object exception. This saves me time and lines of code in my application. My question is, is this good practice? Is it better to let the exception occur and check for null elsewhere?