类方法：在访问变量之前，我应该始终检查变量吗？

Question

Sorry for the stupid question.

Let's say I have this class (code is in C#):

class Foo {
    public List<string> Bars { get; set; }        
    public Foo() { }
}

Now I want to implement a method that perform some operations on Bars , for example Foo.Translate() .

Should I always check that what I am trying to access/modify is not null or valid?

class Foo {
    public List<string> Bars { get; set; }        
    public Foo() { }

    public void Translate()
    {
        // Should I check with a null && count > 0?
        if (Bars != null && Bars.Count > 0)
        {
            [...]
        }
    }
}

Answer 1

It depends.

If the value is null and it shouldn't be, something has obviously gone wrong and whatever you are doing is now an invalid scenario and going to give you wrong results anyways. Let it throw the exception. Check the logs to figure out why it is null, and fix that error.

If it is a valid scenario for the value to be null, it would be appropriate to do what you are doing.

Answer 2

It good practice to validate properties in your constructor and if they are not valid to throw an Exception. That way you can guarantee that every time you will access this property it should be ok. And it's also good o set the property with private setter this way only the constructor or a custom method can update your class properties.

class Foo {
    public List<string> Bars { get; private set; }        
    public Foo(List<string> bars) 
    { 
        if (bars!= null && bars.Count > 0)
        {
         this.Bars = bars
        }
    }
}

Answer 3

You should never expose setters for collections (It is exposing your internals to outside and it violates encapsulation). You should initialize your collection in the constructor. That way you know it will never be null.

There is a code analysis warning for this - https://msdn.microsoft.com/en-us/library/ms182327.aspx

Answer 4

It's all about your expectations. If you expect Foo to require a Bars collection, make the user pass it in the constructor and validate it there (and make it private).

If you expect Bar to be populated within the Foo class, you should ensure that the list is always instantiated in the constructor (and make it private). That will avoid null checks.

If you expect it to have a count > 0 before performing some operation, then, as you have, you should verify that count > 0 before performing that operation.

Answer 5

Because there is a constructor in the code, a value can be checked within the constructor for null values. Typically, if the value is expected to not be null this could be used:

class Foo {
    public List<string> Bars { get; set; }        
    public Foo(string bars) { 
        try
        {
           if(bars == null){ bars = "" } //Whatever value bars should be if null, in this case an empty string.
        {
        catch(Exception)
        {
           throw;
        }

    }
    public void Translate()
    {
        // Should I check with a null && count > 0?
        if (Bars != null && Bars.Count > 0)
        {
            [...]
        }
    }
}

I believe this is faster, as when the object Foo instantiated, any null values are checked.

Answer 6

If something shouldn't ever be null under normal circumstances then don't check. Let the application throw an exception. Otherwise if you do check and it is null , what are you going to do? You could replace the null with something else, but is that value correct?

But the better approach is to control the state of your classes with an iron fist. If List<string> Bars shouldn't be null, don't let it be null. Don't allow an object to place itself in an invalid state, and don't allow other objects to put it in an invalid state. If it can't be null then you don't have to check everywhere. null checks everywhere are a plague, and a sign that we don't know what the state of our code is.

In its simplest form:

class Foo {
    public List<string> Bars { get; } = new List<string>();     
    public Foo() { }
}

You could also do

class Foo {
    private readonly List<string> _bars = new List<string>();
    public List<string> Bars { get { return _bars; } }
    public Foo() { }
}

Now _bars is set to a new List when Foo is created and the compiler will prevent you from ever changing _bars . You can only modify its contents. Now for as long as you work with this class you've removed ever having to worry about whether _bars (or by extension Bars ) is null .

The same goes for methods that return collections or other objects. If there's nothing to return, don't return null . Return an empty array or an "empty" object that the receiving method can work with harmlessly.